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Abstract 


© Copyright IBM Corp. 1995 


This redbook is the result of three projects conducted at the International 
Technical Support Organization, Austin Center. This redbook describes the major 
functions of the IBM OS/2 LAN Server 4.0 product, based on the experiences of 
the systems engineers who participated in the projects. 


The purpose of this redbook is to provide guidance on installing and configuring 
the IBM OS/2 LAN Server 4.0 features. This redbook is intended for IBM 
systems engineers and customers in planning and installing IBM OS/2 LAN 
Server 4.0. A knowledge of IBM OS/2 LAN Server 2.0 or 3.0 is assumed. 


(467 pages) 
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Preface 


This redbook describes the major functions of the IBM OS/2 LAN Server 4.0 
product, based on the experiences of the systems engineers who participated in 
the ITSO, Austin Center, projects. 


The purpose of this redbook is to provide guidance on installing and configuring 
the new features and functions of the IBM OS/2 LAN Server 4.0 product. This 
redbook is intended for IBM system engineers and customers in planning and 
installing IBM OS/2 LAN Server Version 4.0. A knowledge of IBM OS/2 LAN 
Server Version 2.0 or 3.0 is assumed. 


How This Document is Organized 
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The document is organized as follows: 
Chapter 1, “Overview of OS/2 LAN Server 4.0” 
This chapter introduces the major enhancements in OS/2 LAN Server 4.0. 
Chapter 2, “OS/2 LAN Server 4.0 Graphical User Interface” 


The most obvious change in OS/2 LAN Server 4.0 is the graphical user 
interface (GUI). This chapter presents an overview of the GUI, highlighting 
the additional functions available because of it. 


Included are examples of setting up OS/2, DOS, and Windows applications in 
OS/2 LAN Server 4.0. 


+ Chapter 3, “OS/2 TCP/IP and TCPBEUI” 


This chapter discusses how, with OS/2 LAN Server 4.0, you can access a 
TCP/IP network using TCPBEUI, which is NetBIOS over TCP/IP. This gives 
OS/2 LAN Servers and requesters greater accessibilty to WAN environments. 


Chapter 4, “DOS LAN Services and TCP/IP for DOS” 


This chapter describes DOS LAN Services, which replaces DOS LAN 
Requester. This client includes not only the Window interface but also a LAN 
Server graphical user interface, independent of Windows. Information on 
coexistence with IBM TCP/IP for DOS is included. 


Chapter 5, “Peer Services” 


This chapter discusses the optional peer services feature provided with both 
OS/2 LAN Requester and DOS LAN Services. Peer services allows requester 
resources to be shared with users at other requesters. 


Chapter 6, “Command Line and API Enhancements” 


Additions and changes to the OS/2 LAN Server command line interface (both 
from the OS/2 and DOS command prompts) and the application programming 
interface (API) are listed in this chapter. 


+ Chapter 7, “Multiple LAN Adapter Support” 


This chapter describes how to set up your server for greater than four 
adapters. Multiple adapters can help with load balancing, startup 
performance, and fault recovery. 
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Chapter 8, “Migration and Coexistence Among LAN Server Versions” 


This chapter helps you in migrating from from OS/2 LAN Server 2.0 or 3.0 to 
OS/2 LAN Server 4.0. Coexistence among different versions of IBM OS/2 
LAN servers and requesters is also discussed. 


Chapter 9, “LAN Server 4.0 Interoperability” 


This chapter discusses interoperability among OS/2 LAN Server 4.0 and 
other vendors’ clients, such as Windows for Workgroups, NetWare, and 
Windows NT. Likewise, we look at how LAN Server clients work with other 
vendors’ servers. 


Chapter 10, “High Performance File System 386” 


The OS/2 LAN Server 4.0 HPFS386 is described in this chapter. New 
functions include the ability to limit DASD space on directories and disks and 
additional alerts that can be generated. 


Chapter 11, “Fault Tolerance Review” 


This chapter goes over OS/2 LAN Server 4.0 fault tolerance, with examples of 
how to set up and use it. This feature has changed little since OS/2 LAN 
Server 3.0. 


Chapter 12, “Backup Domain Controller” 


This chapter describes the implementation of the backup domain controller 
in OS/2 LAN Server. 


Chapter 13, “Remote IPL” 


The remote initial program load (RIPL) of DOS and OS/2 workstations from 
OS/2 LAN Server 4.0 is detailed in this chapter. CM/2 RIPL is included. 


Chapter 14, “Remote IPL Enablement of DB2 CAE for OS/2 V2.1” 
This chapter extends the remote IPL to the DB2 CAE for OS/2 environment. 
Chapter 15, “Remote IPL of DB2 CAE for Windows V2.1” 


This chapter covers the Windows remote IPL client with DB2 CAE for 
Windows. 


Chapter 16, “OS/2 LAN Server 4.0 CID Enablement” 


Using the LAN CID utility or NetView Distribution Manager/2 can greatly 
decrease your installation time across many workstations. This chapter 
discusses both of these products. 


Chapter 17, “LAN Virtual Device Driver Support” 


This chapter shows how to set up an OS/2 2.11 workstation so that a Multiple 
Virtual DOS Machine (MVDM) session behaves like a native DOS session. 


* Appendix A, “Migration and Backup Utilities” 


This appendix describes utilities that can help you to migrate from previous 
versions of OS/2 LAN Server, including a tool that backs up files when 
changing from a FAT file system to a HPFS386 file system. 


* Appendix B, “ Network SignON Coordinator/2” 
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This appendix provides information on the Network SignON Coordinator/2 
(NSC/2) product, which is shipped with OS/2 LAN Server 4.0. NSC/2 gives 
the user an easy way to sign on/sign off of various products and, in the LAN 
Server multi-domain environment, to easily change passwords across all 
domains. 


* Appendix C, “Open Blueprint” 


This appendix presents an overview of Open Blueprint, which is IBM's 
technical approach for integrated, open, client/server, and distributed 
computing across systems platforms. 


* Appendix D, “Macintosh Client Support” 


This appendix describes how Macintosh clients can access OS/2 LAN Server 
4.0. 


Related Publications 


The publications listed in this section are considered particularly suitable for a 
more detailed discussion of the topics covered in this document. 


IBM OS/2 LAN Server 4.0 Up and Running!, S10H-9679 


IBM OS/2 LAN Server 4.0 Network Administrator Reference, Volume 1: 
Planning, Installation, and Configuration, S10H-9680 


IBM OS/2 LAN Server 4.0 Network Administrator Reference, Volume 2: 
Performance Tuning, S10H-9681 


- IBM OS/2 LAN Server 4.0 Network Administrator Reference, Volume 3: 
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Chapter 1. Overview of OS/2 LAN Server 4.0 


This chapter provides an overview of the OS/2 LAN Server 4.0 new features. 


-—— LAN Server 4.0 README Files 





The OS/2 LAN Server 4.0 README.1ST and README.LS40 files contain 
valuable information on the product that is not contained in the product 
documentation. You should read these before using the product. 











Graphical User Interface 


The most obvious enhancement in OS/2 LAN Server 4.0 is the graphical user 
interface (GUI). The GUI replaces the previous full-screen interface. Some of 
the new functions available to you because of the object-oriented GUI include: 


Drag and drop of resources, users, and groups on the Workplace Shell 


For example, a shared resource can be dragged to a user, and the next 
logon assignment panel is displayed. 


* Ability to assign a resource alias to a group 


User and group setup can be done from the GUI (User Profile Management 
(UPM) continues to be an option) 


Easier multiple domain access and administration 

* Automatic prompting for access control profile creation after alias creation 

* Automatic prompting for applying or propagating the access control profile 
Easier application setup for DOS/Windows applications under OS/2 using the 
DOS Template 


In this manual, we briefly discuss the GUI enhancements. However, for more 
detailed and step-by-step information, see the LAN Server Network Administrator 
Reference Volume 3: Network Administrator Tasks. 





Multiprotocol Transport Services (MPTS) 


© Copyright IBM Corp. 1995 


Network Transport Services/2 (NTS/2) is replaced by Multiprotocol Transport 
Services (MPTS) Version 1.1. MPTS is based on the Multiprotocol Transport 
Network (MPTN) architecture, which provides a general solution for 
interconnecting applications in support of IBM's Open Blueprint structure (see 
Appendix C, “Open Blueprint” on page 449). MPTS has also been called 
AnyNet for OS/2. 


For LAN Server 4.0, the major MPTS enhancement is the capability to run 
NetBIOS over TCP/IP. This function, called TCPBEUI, allows NetBIOS to be 
routed. For more information, see Chapter 3, “OS/2 TCP/IP and TCPBEUI” on 
page 41. 


MPTS includes the following components: 


LAN Adapter and Protocol Support (LAPS) 


This component, as in NTS/2, provides adapter, NetBIOS, IEEE 802.2, LAN 
Virtual Device Driver (VDD), and NetWare Requester support. LAPS contains 
network adapter drivers that provide communication between a protocol and 
network adapters using the Network Driver Interface Specification (NDIS) as 
the interface. 


LAPS has these enhancements: 
- Additional adapter support 


- Capability to do adapter sniffing. This function detects the type of 
adapter that is installed in the machine. 


Note: There may be ISA/EISA adapters that cause the adapter sniff 
function problems due to the procedure used to detect ISA cards on ISA 
and EISA bus machines. If you encounter a problem of this nature while 
installing LAN Server, reinstall with the command INSTALL /NS. This 
command and parameter disables the adapter sniff function. You will 
then have to determine your adapter card manually if using this means 
of installation. 


Socket/MPTS 


This component provides a transport framework that lets Socket applications 
communicate through the Socket API, using TCP/IP, NetBIOS, or Local 
Interprocess Communication (IPC). Socket/MPTS allows TCP/IP applications 
to run over NetBIOS using the non-native networking feature of 
Socket/MPTS. This is possible because the Socket API uses common 
transport semantics across both TCP/IP and NetBIOS protocols. 


Note: A socket is an abstract object that is used to send and receive 
messages. 


The Socket API can be used to communicate over TCP/IP and NetBIOS 
protocols natively, that is, both the transport user and the protocol used to 
transport data are from the same protocol architecture. The Socket API can 
also be used for non-native INET over NetBIOS communications, which 
allows TCP/UDP applications to run over NetBIOS. 


For more information on MPTS, see the Multi-Protocol Transport Services - 
AnyNet for OS/2: Configuration Guide. 





DOS LAN Services 
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DOS LAN Requester is replaced by DOS LAN Services (DLS). The 
enhancements with this product include: 
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Graphical user interface 


DLS users can choose to use the LAN Server GUI or Windows with network 
support. 


LAN Support Program (LSP) is no longer required if you only need NetBEUI 
support 


The LAN support is integrated into the DLS installation; there is not a 
separate LAN support installation as in DOS LAN Requester. Unless you 
choose 802.2 support, then no LSP drivers (DXMxOMOD.SYS) are installed. 


Instead, the CONFIG.SYS file shows the DLSHELP driver, which causes 
NetBEUI to be loaded when NET START is executed (not when the machine 
boots up). 


+ Peer service allows users to share resources at their requesters with other 
users, including users at OS/2 LAN Requesters. 


As with the OS/2 LAN Requester peer service function, only one user at a 
time can have a session with the DLS peer workstation. Security is set at 
the resource level under DLS, that is share-level security is supported (not 
user-level security). 


+ Reduced memory requirements 
Network DDE/clipboard for Windows 


Persistent connection reestablishment, which allows automatic reconnections 
from logon to logon based on the workstation (not the user ID, as is the case 
with assignments). 


This option is configurable in the NETWORK.INI file. 
Enhanced configuration file 


The NETWORK.INI file replaces DOSLAN.INI, and looks like the OS/2 
IBMLAN.INI file. For more information, see “Persistent Connections” on 
page 70. 


Additional command support 


For example, domain/server administration is allowed via the NET ADMIN 
command. 





HPFS386 Enhancements 


The ability to limit DASD space for directories on HPFS386 drives is, for many 
customers, a key new feature in LAN Server 4.0. You can set up a HPFS386 
directory DASD limit from within the Drives folder or using the NET DASD 
command. First, you must enable the drive for this function and restart your 
system. Then you can set limits for directories on that drive. 


In addition to setting the actual space limitation (in KB or MB), you may also set 
a threshold at which an alert will be sent (by default, to administrators in the 
domain). For example, you could specify that the threshold alert be sent when 
80% of the DASD limit is met. A second option is to have additional 
administrator alerts sent at certain intervals, for example, at each 5% increase, 
so that an alert would be generated not only at 80%, but also 85%, 90%, and 
95%. When a user attempts to go over the defined DASD limit (that is, 100% of 
the DASD limit), then that user is sent a message that the operation is 
disallowed. By default, all administrators are also alerted. 


Note: DASD limits do not apply to privileged processes; for example, an 
administrator is exempt from defined DASD limits and is able to go over the 
limit. 


The parameters controlling DASD limits and other HPFS386 parameters are 
contained in a new directory and file, IBM386FS HPFS386.INI. There are good 
descriptions of the parameters included in that file. 
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Dynamic Data Exchange (DDE) 
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The Network Clipboard and DDE functions are provided as a Presentation 
Manager application for OS/2 users and as a Windows application for 
DOS/Windows users. This NetBIOS application allows you to: 


« Share your clipboard with other network users 
* Access other network users' shared clipboards 


* Establish a dynamic data exchange (DDE) link using applications that support 
DDE, between two workstations on the network 


Additional functions let you save a clipping (of clipboard data) to a file to be 
retrieved at a later time, test an application on your workstation to see if it is 
linkable, check to see if a particular machine in the network is actively running 
the Network Clipboard and DDE application, check to see if your DDE link is 
active, allow or disallow other users to access your clipboard and clippings, and 
allow or disallow remote establishment of DDE links with your workstation. 


The network clipboard is an area of memory to which you can copy data and 
share with other users. While the clipboard function allows you to capture a 
snapshot of data with changes to the original not effecting the copy, establishing 
a DDE link between two applications causes changes to the original to also 
change the copy, so long as the link is active. Once an active DDE link is 
established between two applications, the destination application retrieves data 
from the source application. A DDE link address is used to establish and 
maintain the link; this address is stored in the clipboard and can be used in 
problem determination. 


DDE linking requires two applications that support this function. Often times, the 
application will include a Paste Link function which is used by the destination 
application to initialize the link. For a list of applications that are most reliable 
for DDE linking, see the LAN Server 4.0 README file. 


Note: If you have problems establishing a DDE link over the network, try to 
establish the link locally between the same two applications on the same 
workstation. If you are unsuccessful locally, then you will not be able to 
establish the link over the network. 
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Other Enhancements 
Other enhancements in this release include: 
Command line additions 


The philosophy in LAN Server 4.0 is that functions you can do from the GUI 
interface, you should also be able to do from the command line interface. 


New commands include NET APP, to set up and manage network 
applications, and NET DASD, to limit HPFS386 directories. New options 
include /APPLY for the NET ACCESS command, to propagate an access 
control profile down the directory tree, /SCRIPT for the NET USER command, 
to support user logon script files as used in Microsoft networking products, 
and /ASSIGN and /UNASSIGN, to manage user logon assignments. 


Remote installation enhancements 


The new CASSETUP utility, included as part of the MPTS package, is a 
Presentation Manager object-oriented front end for the LAN Configuration, 
Installation, and Distribution (CID) REXX procedure. The LAN CID procedure 
allows you to remotely install CID-enabled products such as OS/2, MPTS, 
OS/2 LAN Requester/Server, CM/2, and DB2/2. 


CASSETUP allows you to define and set up the code server using drag and 
drop functions. The client REXX command files are created automatically for 
OS/2, MPTS, OS/2 LAN Requester, and OS/2 LAN Server. For other 
ClD-enabled products, you can use one of these command files as a 
template and make necessary changes to it. CASSETUP will also create the 
two boot diskettes needed at each client to be remotely installed. 


Note: Although DOS LAN Services is ClD-enabled, CASSETUP only supports 
OS/2 ClD-enabled products. To remotely install DOS applications and 
non-ClD-enabled products, NetView Distribution Manager/2 (NVDM/2), a 
separate product, is required. 


+ Network SignON Coordinator/2 (NSC/2) package added 


NSC/2 is included with OS/2 LAN Server 4.0, and allows you to set up a 
single logon (for DOS and OS/2 clients) to your LAN Server domains, 
NetWare servers, host systems, and local logons (for example, for DB2/2). 
This tool can help you to keep your passwords current on these different 
domains and systems. 


Network application enhancements 


There is a single application folder for your applications, rather than 
separate folders for DOS/Windows and OS/2 applications. In addition, 
because network applications are invoked directly now (that is, the RAS.EXE 
modules are no longer used to invoke the applications), the actual 
application icons for OS/2 and Windows applications are shown in the 
application folder. (For DOS programs, you can create an icon in OS/2.) 
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Productivity aids 


Many administration utilities and applets are included with LAN Server 4.0. 
Unlike previous applets, these are fully supported by IBM. They include the 
following: 


- LSRXUTIL.DLL, or LAN Server REXX utility, which is a comprehensive 
LAN Server API mapper to help the administrator in automating the 
administration of medium to large domains with REXX procedures. For 
example, this DLL can enable user-written REXX procedures to 
create/delete/modify the following: 


- User account definitions 
- Alias definitions 

- Application definitions 

- Access control profiles 
- Logon assignments 

- User scripts 

- Logon profiles 


- Access Control Manager, which helps you to manage your access 
control profiles from a drive or directory tree 


- DCDB export/import utilities for backing up and restoring your domain 
definitions 


- LSLOGOFF, which forces a user off the domain 

- Connection Manager, which helps you manage your connections 

- DIRSTAT, a network adapter status tool 

- MOVESTUF, which moves/copies file resources around your network 
Longer names supported 


You can use up to 15 characters for machine ID and domain names. For 
user and group names, up to 20 characters can be used; however, it is 
recommended you not use more than 15 characters in order to receive 
messages (NetBIOS messaging name restriction). 


Note: Be aware that if you have LAN Server for Macintosh clients, there is 
currently a problem if you use names more than eight characters in length. 

If there are LAN Server for Macintosh clients in your network, do not use 
more than eight character names for your names. For more information, see 
Appendix D, “Macintosh Client Support” on page 453. 


+ Logon to another domain from server 
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From a server, you are now able to logon to another domain. 





Chapter 2. OS/2 LAN Server 4.0 Graphical User Interface 


This chapter provides an overview of the new graphical user interface (GUI) that 
is included with OS/2 LAN Server 4.0. This user interface is object-oriented to 
allow the user or system administrator to configure and use the network via the 
manipulation of visual objects. The paradigm used has a consistent look and 
feel with the Workplace Shell (WPS) that is currently in the OS/2 2.X and OS/2 
Warp product set. 


Notes: 


1. To get all of the WPS/GUI functions, the prerequisite for LAN Server 4.0 is 
OS/2 Warp (with or without WinOS/2). 


2. We have selected a few tasks to show you using the GUI. For more 
information and step-by-step instructions for using the GUI, see the LAN 
Server Network Administrator Reference Volume 3: Network Administrator 
Tasks. 





Drag and Drop of Objects 


© Copyright IBM Corp. 1995 


With the new object-oriented graphical user interface, OS/2 LAN Server 4.0 can 
take advantage of drag-and-drop capabilities used in other OS/2 applications and 
in OS/2 itself. The drag-and-drop technique, which draws on how humans 
ordinarily treat real objects, is a major function of graphical user interfaces in 
general. Those who do not like the drag-and-drop technique can use the 
pull-down menus instead. OS/2 LAN Server 4.0 offers both methods. 


In the example shown in Figure 1 on page 8, you can see five folders opened in 
a logical path. That is: 


LAN Server Administration, opened from the main IBM LAN Services folder 
Domain contents, opened by double-clicking on the domain object (here 
named ITSCAUS) 


Within the ITSCAUS folder: 
- User Accounts 

- Groups 

- Resource Definitions 
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Figure 1. Drag and Drop of Objects 
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Example: Assigning a resource to user accounts and groups 


In the Resource Definitions folder, we have defined a printer resource called 
IBM4079. To assign that resource, for example, to the user ID LAURENE, 
simply drag and drop the IBM4079 object to the user ID object LAURENE. 
You will then have the chance to add or replace access permissions for the 
user in the Grant Access to Resource panel, and also to select the logical 
port that will be assigned to this resource when the user logs on in the 
Administer Logon Assignments panel. 


The result is that the user LAURENE now has the resource IBM4079 as a 
logon assignment. Similarly, you could drag this resource to many different 
users, or drag many resources (that you have highlighted by pressing the 
Ctrl key while selecting) at once to a user. 


You can also drag and drop that resource to one or more group IDs. The 
result is that the resource is then assigned to each user in that group. 


Note: After dragging a resource to a group and making it a logon 
assignment, you are able to go back later and either change or delete the 
assignment for the group. 


To do this, drag the resource back to the group (just as you did when you 
made the assignment), and select Continue in the Grant Access to Resource 
panel to go back to the Administer Logon Assignments panel, where you can 
change the assignment or delete it. 


Example: Assigning users to a group 


In the Groups folder, we have created the LS40 group. If we now would like 
to include the users LAURENE and MARCIO in that group, we simply drag 
and drop each user object to the LS40 group object. You can do this with 





croup Template L540 OBJECTS DSMGROUP DSZGROUP . 

















IBM4079 APPL-DRW APPL-EXL APPL-FLG APPL-LPX 


one action by pressing the Ctrl key while selecting all users, and then 
dragging and dropping them on the LS40 group object. 


Example: Creating a user ID 


It is also very easy to create new objects with the templates. To create a 
new user ID, drag a copy of the UserID Template to an open area in the User 
Accounts folder. Then the User Account Create settings notebook is 
displayed, and you can begin to complete the fields. 


Example: Creating a group and aliases 


Using the same drag-and-drop concept, you can easily create new groups 
with the Group Template in the Groups folder. The same procedure applies 
to new Printer, Serial Device or Directory aliases with the templates in the 
Resource Definitions folder. 


User Account Create Notebook 


With OS/2 LAN Server 3.0, User Profile Management (UPM), an interface 
separate from the LAN Server full-screen interface, was used to create and 
manage users and groups. With OS/2 LAN Server 4.0, you can still use UPM to 
manage users and groups. However, not all features that come with OS/2 LAN 
Server 4.0 will be offered in UPM. For example: 


Creating user IDs (type User, not Administrator) with specific privileges that 
allow: 


- Managing printer queues 

- Managing groups and users 
- Managing serial devices 

- Managing shared resources 


* Assigning home directories to user IDs 
+ Administering logon assignments and public application assignments 


If you want to get all OS/2 LAN Server 4.0 user/group management features in 
one interface, you should use the User Account Create notebook to manage 
users and the Groups Create notebook to manage groups. 


Figure 2 on page 10 shows you what you can do with the User Account 
Notebook and gives you an idea of why it may suit your needs better than UPM 
for managing LAN Server users and groups. 


Within the User Account settings notebook, you can browse, create, delete and 
modify the settings for a user account. These settings include the identity, 
password, account information, home directory, logon assignments, public 
applications, and groups that this user belongs to. 


Notes: 


1. The user account name can be up to 20 characters. However, if you have 
DB2/2 (up to version 1.2) installed, then you should make the User account 
name no more than eight characters for compatibility reasons. 


2. If the user account name is more than 15 characters, it cannot be added to 
the network as a messaging name, and the user cannot send or receive 
messages. 
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3. In the User account name field, you cannot use the NLS characters 130 
though 139 (using the ALT-numbers technique), since the 13 is interpreted as 

a carriage return and you are now on the next page. Also some characters 
(from 140 - 150) are not entered correctly. 

. Be aware that if you have LAN Server for Macintosh clients, there is 
currently a problem if you use names more than eight characters in length. 
If there are LAN Server for Macintosh clients in your network, do not use 
more than eight character names for your names. For more information, see 


Appendix D, “Macintosh Client Support” on page 453. 
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Figure 2. User Account - Create Settings Notebook 


In Figure 2 you can use the following notebook pages to change or display 
different settings for a user account: 


Use the Identity notebook page to display or change identifying information 
about the user account. 


Use the Password notebook page to change the password for the user 
account. 


Use the Privileges notebook page to display or change information about the 
privilege levels. 


Use the Home Directory notebook page to display or change home directory 
information for the user account. 


* Use the Account Info notebook page to display or change information about 


a user's account options. 


* Use the Assignments notebook page to display or change the logon 


assignments assigned to the user account. 


- Use the Applications notebook page to define public applications for the user 
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account. 


Use the Groups notebook page to display or change the groups of which the 
user account is a member. 





Logon Assignments and Logon Profiles 


In this section, we discuss general logon assignment and logon profile 
considerations. 


In some cases, especially in previous full-screen interface LAN Server versions, 
administrators preferred using particular logon profiles for each user to assign 
printer aliases and file aliases. Since OS/2 LAN Server 4.0 now has a graphical 
user interface, there is not as much of a need for individual profiles. However, 
existing profiles will still run under OS/2 LAN Server 4.0. 


The DOS user's profile is named PROFILE.BAT, and the OS/2 user's profile is 
named PROFILE.CMD. Both files reside in the IBMLAN DCDB USERS userlD 
subdirectory on the domain controller. 


A typical PROFILE.CMD for OS/2 users could look like Figure 3. 


[8 ORK KK KK IK I RK / 


/* User Profile in REXX */ 


[RRR KKK KKK KKK KK KK KK KKK / 





'@ECHO OFF' 
trace 0; 








"NET USE LPT1: \\ITSCSV00\IBM4079 >NUL' 
'IF EXIST X:\LANUSER.CMD CALL X:\LANUSER.CMD' 

















exit 0; 











Figure 3. PROFILE.CMD for OS/2 Users 


Note: REXxX is only available to OS/2 users except if you use PC DOS 7.0. With 
PC DOS 7.0, the PROFILE.BAT file also can be a REXX command file. 


A typical PROFILE.BAT for DOS users could look like Figure 4. 





@ECHO OFF 














NET USE LPT1: \\ITSCSVO0\IBM4079 >NUL 
IF EXIST X:\LANUSER.BAT CALL X:\LANUSER. BAT 














Figure 4. PROFILE.BAT for DOS Users 


One of the major advantages of having profiles is flexibility. However, with OS/2 
LAN Server 4.0 interface, you have got at least the same flexibility now. If global 
changes have to be made, you simply can use the GUI. 


Note: You cannot make network application assignments using PROFILE.CMD 
and PROFILE.BAT. 


For example, let's say you would like to change printer assignments for the LS40 
group as shown in Figure 5 on page 12. The users belonging to the LS40 group 
have the printer alias IBM4079 assigned to LPT1. Because the users now have 
local printers attached to LPT1, you want to assign the network printer to their 
logical LPT2 port. 
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You can do this as follows: 
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Figure 5. Changing Printer Assignments 


1. Drag and drop the IBM4079 printer object to the LS40 group as you would 
assign the printer to the group. The Grant Access to a Resource settings 
notebook is opened. Select Continue.... 


2. In the Administer Logon Assignments window shown in Figure 6 on page 13, 


you easily can make the change needed. In this example, select the Add 
assignment button. 
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Figure 6. Administer Logon Assignments Window 


3. Change Local device name from LPT1 to LPT2. Place a check mark in the 
appropriate box, for example Replace existing logon assignment and/or 
Replace conflicting device assignments. You also may delete the printer 
assignment if you need to do so. 


4. Select OK to complete the change. 
Using logon profiles, you would have changed the line for the printer for each 


user, or changed a command in a file called by the logon profile (such as 
LANUSER.CMD and LANUSER.BAT, as shown in the figures on page 11). 





Access Control Profile Creation 


In previous IBM LAN Server versions, the administrator had to remember to 
define an access control profile after the definition of an alias. Then, to 
propagate that profile down the directory tree, the administrator had to use the 
Apply function from full-screen interface. 


With OS/2 LAN Server 4.0, you are prompted to create an access control profile 
after the creation of an alias. After creating the profile, you are prompted to 
propagate it down the tree. 


In Figure 7 on page 14, you can see the system tells you that an access control 
profile does not exist for the resource you have just defined with an alias. By 
taking the default and clicking on the OK button, the window in Figure 8 on 
page 14 is displayed. 
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Figure 7. Access Control Profile Does Not Exist Window 


In the Access Control Profile - Settings View notebook, shown in Figure 8, you 
can now set the permissions and the auditing settings for the alias. 
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Figure 8. Access Control Profile - Settings View Notebook 


After pressing the Set button, the Propagate Access Profile to Subdirectories 
window is displayed as shown in Figure 9. By taking the default and pressing 
the OK button, the access control profile is propagated to all of the resource's 
subdirectories. 


Select OK to propagate this access 
® control profile to all of the 
: resource’s subdirectories. 
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Figure 9. Propagate Access Profile to Subdirectories Window 
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Network Applications 


This section provides examples of installing OS/2, DOS and Windows network 
applications running on an OS/2 LAN Requester 4.0. 


A new feature of LAN Server 4.0 is the ability to represent the public and private 
applications by their actual product icons in one single folder named Network 
Applications (at the client's workstation). This is because the RASx.EXE 
programs are no longer used to invoke applications. Now, all programs are 
started directly by the actual application's executable file. 


Also, you can now define DOS and Windows applications for DOS and for OS/2 
users using DOS Templates. Since OS/2 reads information from the EXE header, 
it is able to start the correct environment, so that, for example, the execution of 
the Windows version of AMIPRO really starts a Windows environment at the 

OS/2 client. Because applications icons are stored in the EXE file as well, the 
real icons are shown in the Network Applications folder. 


In the past, to define DOS and Windows application for OS/2 users, you had to 
create OS/2 command files, which were invoked from inside an OS/2 application 
definition. OS/2's ability to read the EXE header was used here. 


Note: Make sure you fulfill all license agreements when you install applications 
on the server. Applications you share in your network must be enabled to run 
over a network. 


Installing an OS/2 Public Application 


The following steps show you how to install Lotus 1-2-3 for OS/2 as an OS/2 
network application located at a server: 


1. Make a decision where to install the application on the server. 


2. Install the application on the server. Follow the instructions that come with 
the product. For Lotus 1-2-3, for example, you may use the path D: 123G. 





3. In the LAN Server Administration folder, double-click on the Domain object. 


4. Before you actually create a public application for Lotus 1-2-3, you first have 
to create a directory alias that points to the subdirectory on which Lotus 
1-2-3 was installed (in our example it is D: 123G). 


5. Double-click on the Resource Definitions object. 
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Figure 10. Resource Definitions Folder 


6. In the Resource Definitions folder (as shown in Figure 10), drag and drop a 
copy of the Directory Template to an open area in the Resource Definitions 
folder. The Directory Alias - Create settings notebook is opened, as shown 
in Figure 11 on page 17. 


In the Directory Alias - Create settings notebook, complete the Identity page. 


Consider license control. In our example, we purchased 10 licenses of Lotus 
1-2-3. So the value in the Number of connections field should be set to 10. 
OS/2 LAN Server 4.0 ensures that no more that 10 users will be able to start 
the application. 


Note: Some network-enabled applications come with their own license 
control. If this is the case, carefully read instructions that come with the 
product. In most cases, it is enough to assign a so-called work directory 
(see Figure 16 on page 19) that points to the subdirectory in which license 
control files reside. 


7. Select Create. 
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Figure 11. Directory Alias - Create Notebook 


The following window is displayed: 





An aceess contral profile for this 
resource does not exist, select OK 
to create. 
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Figure 12. Access Control Profile Does Not Exist Window 


8. Select OK. 


The Access Control Profile - Settings View notebook is displayed. 
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Figure 13. Access Control Profile - Settings View Notebook 


9. Complete the permissions page as shown in Figure 13. In this case, all 
defined users will get Read and Execute rights. As in previous LAN Server 
releases, the USERS group is a special group to which all defined users 
belong. 


10. Select Create. 


The following window is displayed: 





Select OK to propagate this access 
® control profile to all of the 


resource’s subdirectories. 
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Figure 14. Propagate Access Profile to Subdirectories Window 


11. Select the OK button. 


Since you just created the file alias for Lotus 1-2-3, you can now continue by 
creating a public application (also called network application) for Lotus 1-2-3. 


12. To do so, double-click on the Public Application Definitions object. 


The Public Applications Definitions window will be opened. It is shown in 
Figure 15 on page 19. 
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Figure 15. Public Application Definitions Folder 


13. In the Public Applications Definitions folder, drag and drop an OS/2 Template 
to a free area of the folder. 


The OS/2 Application Definition - Create settings notebook is displayed as 
shown in Figure 16. 
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Figure 16. OS/2 Application Definition - Create Settings Notebook 


14. In the OS/2 Application Definition - Create settings notebook, complete the 
Identity, Invocation, Program Location and Work Directory pages. The 
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15. 


16. 


17. 


Program Location in this Lotus 1-2-3 example is on the server. The directory 
alias LOTUS123 (created in the steps before) has to be used. 


Note: For other applications that come with their own license control, you 
probably need to assign a drive that points to the license control software. 
After having created a file alias for this particular license control software, 
you may assign this alias by using either the Work Directory or Network 
Resources page. 


Select Create. 


Now that you have created a network application, you may assign it to a user 
or group. 

In the domain controller contents folder, double-click on the User Accounts 
folder and the Groups folder. 


Drag and drop the new created Lotus 1-2-3 application object to the user or 
to the group who have the Lotus 1-2-3 product selectable from their Network 
Applications folder after successful logon. 


Installing DOS and Windows Public Applications 
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The 
simi 


steps to be followed to define DOS and Windows public applications are 
lar to the ones described in “Installing an OS/2 Public Application” on 


page 15. 


The 
1. 


steps are as follows: 


Install the DOS or Windows application on the server. Follow the instructions 
that come with the product. 


. Create a file alias. 


3. Create an Access Control Profile for the alias. 


4. Create a DOS or Windows Public Application using the DOS Template as 
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shown in Figure 17 on page 21. 


With previous LAN Server products, the LAN administrator had to create an 
OS/2 command file that invoked the DOS or Windows application. This 
command file was then defined as an OS/2 public application. With OS/2 LAN 
Server 4.0, the LAN administrator can now use the DOS Template to define 
DOS and Windows public applications. In addition, the LAN administrator 
defines the real program executable file. 
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Figure 17. Public Application Definitions Folder 


5. In Figure 18 complete the Identity, Invocation, Program Location, and Work 
Directory pages. 
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Figure 18. DOS Template - Settings View Notebook 


6. Add the DOS or Windows application to the user's Network Application 
folder. 


After you have installed and configured the network applications and assigned 
them to the appropriate users, these users will receive the Network Applications 
folder after successful domain logon. Figure 19 on page 22 shows an example 
of how this folder looks with the Lotus 1-2-3 application: 
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Figure 19. Network Applications Folder 


In LAN Server 4.0, the program settings page of a user's network application 
contains the actual application that is being invoked, unlike in previous releases 
where the application was invoked by one of the three OS/2 programs 
(RAS1.EXE, RAS2.EXE, RAS3.EXE) and the alias. In addition, each program 
object now has the icon that corresponds to the program rather than only the 
standard OS/2 icon. 


OS/2 and Windows programs normally have an icon associated with the 
program. DOS programs don't have icons. However, as shown in Figure 19, you 
can see our DOS program (Wordperfect for DOS) has an icon associated with it. 
To associate an icon to a DOS program, do the following: 


1. Create an icon with the OS/2 Icon editor as shown in Figure 20 on page 23. 


2. Copy the icon to the directory in which the DOS executable program file 
exists. 


3. Name the icon the same as the DOS executable program file name. The file 
extension of an icon file always is .ICO. 


In our example, the DOS program is called WP.EXE; the name of the icon file 
must be WP.ICO and must be placed in the same directory in which the EXE file 
resides. The same rule applies to batch (.BAT) files. 
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Figure 20. Icon Editor Window 
-— OS/2 and DOS Application Considerations 


Consider the following rules: 
You can have up to 140 public applications. 
You can have up to 140 private applications per user. 
You can have up to 400 public DOS applications. 
* You can have up to 400 private DOS applications per user. 


The description field of an alias can be up to 40 characters. If you use 
now all the 40 characters then you can have up to 177 aliases. If you 
make the description field as short as possible you can have up to 800 
aliases. 





Dynamic Link Library Considerations 


Most OS/2 applications require access to Dynamic Link Library (DLL) modules to 
run. There are two alternatives available to do this: 


Ensure that the requester's machine has a period in the LIBPATH statement 
in the CONFIG.SYS file, so the current directory is searched for DLLs. This 
method relies on the user not changing the current directory while using the 
networked application. 


Create another alias for all DLLs, and have users also connect to this as one 
of the logon assignments (or working directory). 


An extra setup step is then required to copy DLLs to the common DLL 
subdirectory for the public applications. The access control profile should be 
created and the DLL alias should be assigned a drive for the user at logon 
time. In addition, the OS/2 requester workstation needs to modify its 
LIBPATH statement in CONFIG.SYS, to access the common DLL on the 
server. 
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Defining Network Applications from the OS/2 Desktop 


The OS/2 desktop supports seamless interfaces to the application object. The 
user doesn't need to be aware of where the application is located. If itis a 
network application, a logon screen will appear with the appropriate logon panel 
when the object is double-clicked. If the application belongs to a LAN Server, its 
logon panel will appear. If it belongs to a NetWare server, the NetWare login 
window will appear. Here, we discuss the steps to define the network 
applications and how they must be defined to run correctly. 


Creating a Network Application Using Templates 
The following steps show you how to define a network application from a 
template: 


1. Drag and drop a Program template from the Templates folder to an open 
area on the OS/2 desktop. 
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Figure 21. Program Template Notebook 


2. In Figure 21, in the Path and file name field, enter the Universal Naming 
Convention (UNC) of the application. You can use the Find function to help 
locate the shared resource. 


In the Working directory field, you can enter a working directory. 


3. Specify the name of the application in the General page of the notebook. 





Multiple Domain 


Administration 


In the following IBMLAN . INT file, you can see that we have specified additional 
domain names by using the othdomains (other domains) parameter. Using this 
parameter you can specify up to four domains separated by commas. To have 
the ability to administer up to the maximum of six domains you just have to 

logon to a domain that is neither specified by the DOMAIN parameter nor specified 
as a domain by the othdomains parameter. The DOMAIN and othdomains 
parameters are shown in Figure 23 on page 26. 
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To administer different domains from one workstation, you must have set up the 
same user IDs and passwords on all domains you want to administer. This is an 
absolute prerequisite! 


A useful tool to ensure synchronized passwords on all domains you would like to 
administer is Network SignON Coordinator/2 (NSC/2), which is also shipped with 
the OS/2 LAN Server 4.0 product. 


Note: For more information about the Network SignON Coordinator/2, please 
refer to Appendix B, “ Network SignON Coordinator/2” on page 433. 


; OS/2 LAN Server Advanced initialization file 


[networks 
net1l = NETBEUIS,0,LM10,100,200,14 

; This information is read by the redirector at device initialization time. 

[requester] 

COMPUTERNAME = ITSCSV0O0O 

DOMAIN = ITSCAUS 

; The following parameters generally do not need to be 
changed by the user. 

charcount = 16 

chartime = 250 

charwait = 3600 

keepconn = 600 

keepsearch = 600 

maxcmds = 16 

maxerrorlog = 100 

maxthreads = 10 

maxwrkcache = 64 

numalerts = 12 

numcharbuf = 10 

numservices = 16 

numworkbuf = 15 

numdgrambuf = 14 

othdomains = LS40DOM, ACCTDEPT, FINANCE, PERSONNEL 

printbuftime = 90 

sesstimeout = 45 

sizcharbuf = 512 

sizerror = 1024 

sizworkbuf = 4096 

useallmem = No 






































Figure 22. Extract of the IBMLAN.INI file to ensure Multiple Domain Administration 


In the example shown in Figure 23 on page 26, we are logged on to the 
ITSCAUS domain. Because of the changes made to the othdomains parameter 
(shown in Figure 22), we are now able to administer the LS40DOM, ACCTDEPT, 
FINANCE and PERSONNEL domains as well. 


Note: Although cross-domain administration is possible while logged on to one 
domain, you cannot drag and drop objects from one domain to other domains. 
To set up cross-domain resources, see “Creating Cross-Domain Resource 
Definitions” on page 26. 
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Figure 23. Administering Multiple LAN Server Domains 





Creating Cross-Domain Resource Definitions 


The following steps show you how to create an alias for a resource outside of 
the current domain, called a cross-domain resource or external alias by using 
the GUI: 


1. Within the domain controller content folder, double-click on the Resource 
Definitions object. 


2. Drag and drop a Directory Template to an open area in the Resource 
Definitions folder. 


The Directory Alias - Create settings notebook will be opened. It is shown in 
Figure 24 on page 27. 
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# CIDTREE 


Description 
Server name # 


When shared 

AL server startup 

y When requested 

4 By administrator action 


, Maximum concurrent connections 
#/ Unlimited 
yAumber of connections 


ed number of users can share this resource 





Figure 24. Directory Alias - Create Settings Notebook 


3. Enter values as follows: 


* Alias - Type in the netname (sharename) of the resource on the external 
server 


Note: It is assumed that the resource is already shared on the external 
domain, which is a requirement for cross-domain access. 


* Type in a description as you like 
- Server name - Type in the name of the external server 


Note: Do not use the pull down menu here since the external server 
does not belong to the current domain. 


+ Path - Type in the drive and path to the resource on the external server 
+ Select shared when requested or At server startup. 
4. Press the Create button. 
As with any resource, for the user to successfully use the cross-domain 
resource, access permissions must be set properly. Ensure that either you (if 


you are the administrator on both domains) or the administrator of the other 
domain does at least one of the following: 


1. Set up the user ID (with the same passwords) in both domains, and then 
grant permissions to the resource in the other domain through the user ID. 


2. Grant the desired access permission to the resource through the GUEST 
user ID on the external domain. 


You can do one or both of the above so that users can then access the 
cross-domain resource transparently; that is, the resource appears to be in the 
local domain. If the user ID is not known to the external domain, then the user 
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will be granted the GUEST user permissions. If the user ID is known to the 
external domain, then the user is granted the permissions for that ID. 


Note: If the user ID is known on the external domain, but the passwords are not 
the same on both domains, then the user can still access the cross-domain 
resource by specifying the external password when requesting resource use, for 
example: 





NET USE X: TEMP password 

















Managing Machines 


This section shows how you can define additional servers and shadowed severs 
via the GUI. 


In Figure 25 you can see the following four folders: 


¢ LAN Server Administration 

* Domain Controller contents (ITSCAUS) 
+ Shadowed Servers 

* Defined Servers 
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Figure 25. Additional Servers and Shadowed Servers 


Defining an Additional Server 
The following steps show you how to define an additional server: 


1. Double-click on the ITSCAUS icon in the LAN Server Administration folder. 
The folder ITSCAUS domain controller contents will be opened. 
2. In the ITSCAUS folder, double-click on the Defined Servers object. 
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The Defined Servers folder will be opened. 


3. To create an additional server, drag and drop a Defined Servers Template to 
an open area in the Defined Servers folder. 


The Defined Servers - Create settings notebook will be opened. Now you 
can specify the settings for the additional server. As a result you have an 
additional server object in the Defined Servers folder. In our example, the 
server name is ITSCSV01. 


Defining a Shadowed Server 


The Shadowed Servers folder just displays shadows of servers that are defined 
in the Defined Servers folder. Use this folder to have shadows of servers for a 
quicker access to the servers you administer most often. This may be useful if 
you are administering multiple domains from the GUI, and would like to group 
the servers in one folder. 


To make a shadow of a server, drag any server from a Defined Servers folder 
and drop it in the Shadowed Servers folder. In our example, we dragged the 
ITSCSVO1 object from the Defined Servers folder to the Shadowed Servers folder. 


Have a look at the following steps to see what exactly can be done with local 
and additional servers: 


1. Select the server you would like to administer in the Shadowed Servers 
folder or in the Defined Servers folder. In our example, the local server 
ITSCSVOO is used. 


2. Choose the pull down menu item Selected, click on the right arrow of Open. 


This shows you a list with the following menu items: 
* Open files 


Select this menu choice to display a list of files that are open on this server. 
Files can be closed by using the Open Files window. 


Active sessions 


Select this menu choice to display a list of sessions that are active on this 
server. Sessions can be deleted by using the Active Sessions window. 


Statistics 


Select this menu choice to select the type of statistics to display. You can 
choose server or requester statistics. Statistics can be refreshed, printed or 
cleared by using the selected Statistics window. 


* Current shared 


Select this menu choice and then select Directories, Printers or Serial 
Devices to display or change the devices currently shared by this server. 


Current assignments 
Select this menu choice to display a list of the current device assignments 
that are active for the workstation. 


Figure 26 on page 30 shows you that we also can administer the services on 
local and additional servers by first double-clicking on the server object and then 
double-clicking on the Services object. We then can start, stop or pause 
services on local and additional servers. 
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DCDB Replicator service DCDBREPL : Service never started 
DLRINST DLRINST : Service never started 


Generic alerter service GENALERT Service never started 


LSclient service LSCLIENT Active 
LSserver service LSSERVER Active 
Messenger service MESSENGER | Active 
Netlogon service NETLOGON Active 
Netpopup service NETPOPUP Service never started 
Netrun service NETRUN Service never started 
Remote IPL service REMOTEBOOT Service never started 
Replicator service REPLICATOR | Service never started 
Requester service REQUESTER Active 
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Figure 26. Server Services 


Server - Settings View Notebook 
In this section, you will find information about server settings and what you can 
administer within the server settings notebook. 
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1. 


The 
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In the LAN Server Administration window, select either Local Workstation 
object if your local workstation is a server or go to the Defined Servers folder 
or Shadowed Servers folder and select one server. 


. Press the right mouse button for object manipulation 
. Select the right arrow of the Open item 


. Then select Settings 


opened server settings notebook is displayed in Figure 27 on page 31. 






sceceeccecccceeceecedccdedecieesieaseniel 
2 
SADR BEd Dae ten se MS EA eae cM alee Reh IE A A Soltek elie 8k lie tk tle tate tlle ote tlie te eT te LA 









erver name... 1TSCSV00 


Z 
Y, 
y, 
Ye 
Ye 


5 
/ Description 


AAI Ly / 
Me = OF 
Primary server ITSCSV00 fcces | 


so “| : 
rae | 


: imation about the server ce i | 















Figure 27. Server - Settings View Notebook 


You can use the following notebook pages to change or display different settings 
for the server: 


* Use the Identity notebook page to display the server name and other 
descriptive information about the server. You can also change the comment 
in the Description field. 


* Use the Workstation notebook page to display the workstation name and 
other descriptive information about the workstation. 


* Use the Alerts notebook page to specify alert recipients. An alert is a 
notification about an event that usually indicates an error, either on the 
network or in a user operation. Typical events for which alerts are sent 
include logon violations, access violations, or a decrease in available disk 
space below some acceptable level. 


Alert recipients may be specified as user IDs or machine IDs. 


+ Use the Announcements notebook page to display or change information 


about the frequency with which this server announces its presence on the 
network. 


- Use the Buffers notebook page to display information about the server 
buffers provided. 


* Use the Limits notebook page to display information about the limits the 
server sets for activity on the network. 


* Use the Auditing notebook page to display the types of events that can be 
audited for this server. It also displays which events are audited when 
auditing is enabled on the server. If the status field of an event is blank, the 
event is not audited. The following events can be audited on a server: 


- Service state changes 
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Successful session requests 

Unsuccessful session requests 

All session requests 

Successful domain logon requests 

Unsuccessful domain logon requests 

All domain logon and logoff requests 

All domain logon and session requests 
Successful share requests 

Unsuccessful share requests 

All share requests 

Changes to the user and group account database 
- Changes to the access control database 

- Resource access as defined by per resource auditing options 
- Logon limit violations 


+ Use the Time-out notebook page to display or change information about 
time-out conditions on the server. 





Network Dynamic Data Exchange and Clipboard 
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OS/2 and Windows workstations feature a clipboard, which is an area of memory 
to which you can copy data. Therefore, it follows that a network clipboard is an 
area of memory to which you may copy data that you wish to share with other 
users. In addition, users have the capability to take a data item from an 
application and save this information with a named string for future retrieval. 

This data item is called a clipping, and it enables several sets of data to be 
shared at the same time. A clipping contains not only the data item but also the 
information necessary to establish a DDE link. 


Network Dynamic Data Exchange (DDE) and Clipboard on is a NetBIOS 
application (shipped as part of both DOS LAN Services and also the OS/2 LAN 
Requester) that extends DDE capabilities and the clipboard across the network. 
It enables users running various applications, with clipboard copy-and-paste 
capabilities, to connect to each other remotely and share data through the 
clipboard and files saved from the clipboard. 


The network functions supported by this application include the following aspects 
of DDE: 


* Initiate 

* Request 

* Advise 
Unadvise 
Poke 

* Execute 


Network DDE and Clipboard does not create a network clipboard; it allows other 
users access to your local clipboard and allows you to access other users’ 
clipboards. 





-—— Problem with Warp as Network DDE Source 


In the initial release of OS/2 LAN Server 4.0, there is a known problem using 
network DDE with an OS/2 Warp workstation as the source. The problem is 
documented in APAR PJ17136. 
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Starting Network DDE and Clipboard 
Before this feature may be used, you must have first performed the following 
steps to get Network DDE and Clipboard up and running: 
Logon to an OS/2 LAN Server 


* Select the Network DDE and Clipboard icon from the DOS LAN Services 
program group or LAN Services folder depending upon whether you are 
logging on from a Windows or OS/2 requester. 


* Select Control Access from the following menu: 





Figure 28. Network DDE and Clipboard Main Panel 


Define global access from the menu that is subsequently displayed. 


Dd Allow remote access to your clipboard 


C4) Allow remote access to your clippings 


C4) Allow remote establishment of DDE links 


Local workstation is DLSREQOD? 





Figure 29. Network DDE and Clipboard Control Access Panel 


Note: Your clipboard is not like other resources in OS/2 LAN Server; you can 
neither allow nor deny access for specific users. To stop users from accessing 
information from your clipboard, deselect this option. This option is active by 
default. 


Using and Sharing Data 
In this section, we will look at scenarios which demonstrate the ways that you 
may both use and share data through the Network DDE and Clipboard feature. 
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Copying Data 

In the first instance, let's look at how you can copy data through Network DDE 
and Clipboard from an application on one workstation to an application on 
another workstation. 


This method may be applied to the situation where a daily sales report, 
incorporating comments from the regional sales manager, is produced in Ami 
Pro on one workstation using sales data stored in Lotus 1-2-3 on another 
workstation. 


After the data has been copied, changes to the original version of the data have 
no effect on the copied version. Therefore, in this scenario the report will only 
produce a snapshot, which may be of use when printed. 


Linking Data 
In this scenario, the data in one application is linked to the data in another 
application running on another workstation. 


If we continue the scenario looking at daily sales reports, in this instance to 
ensure that the sales figures are as current as possible, the workstation that is 
the source of sales data for the regional sales office accesses sales data that is 
constantly updated in the sales order processing department. 


After you have linked to the data, the copied version on the other workstation 
has been updated automatically with changes to the original version. 


Sharing Data - Clipboard 
Data may be shared through the clipboard; however, the data must remain 
available in the clipboard for it to be accessible. 


This feature would allow the sales secretary to make the regional sales 
manager's comments available for the analyst to include in the report. 


This is achieved through the Copy Clipboard option. 


Copying Data - Clippings 

In this instance data does not need to remain in the clipboard for it to be 
accessible. Clippings are clipboard data sets that are saved to disk. They and 
let you concurrently share several sets of data with remote users. 


This would allow the order processing department to maintain copies of previous 
sales figures to enable regional analysts to produce periodic reports. 


Clipboard data that has been saved as a clipping through the Manage Clippings 
route is copied via the Copy Clipping option. 


Considerations for Linking Data over the Network 
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Par of this section is taken from the LAN Server 4.0 README file. 


To create DDE links between applications and enable automatic updating of 
information, each application participating in a link must support DDE linking and 
include a Paste Link menu choice. The following examples of applications that 
support DDE linking are grouped in order of ease and reliability in establishing 
DDE links across a network: 
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Easiest and most reliable: 
- Excel for Windows 4.0, 4.0a, 5.0 
Generally successful: 


- DeScribe 4.0E 

- Lotus 1-2-3 for OS/2 2.1 
- Word for Windows 2.0 

- CA-Textor for OS/2 6.0 
- Word for OS/2 1.1b 


Difficult or generally unsuccessful: 


- Lotus 1-2-3 for OS/2 2.0 
- WordPerfect for OS/2 5.2 
- Word for Windows 6.0 

- Ami Pro for OS/2 3.0A 

- Ami Pro for Windows 3.0 


Also, Windows applications that support clipboard copy-and-paste operations 
running in a Win-OS/2 session can be used with Network DDE and Clipboard. 


Note: For OS/2 requesters to establish network DDE links between Windows 
applications, the following Win-OS/2 settings need to be set: 


+ VIDEO_8514A_XGA_IOTRAP=OFF 
+ VIDEO_SWITCH_NOTIFICATION=ON 


Linkable Data 

You can use DDE to create a dynamic link between the data in two applications. 
In a dynamic link, one application (called the DDE destination application) 
retrieves data from a second application (called a DDE source application). The 
DDE destination application's data is updated automatically whenever the data 
retrieved from the DDE source application changes. 


A DDE link address is necessary for establishing a link. A DDE link address 
includes: 


Source application name Name of the source application; for example: 
Microsoft Excel, Lotus 1-2-3, Microsoft Word. 


Topic name Name of the file or the document that contains the 
item to be linked. 
Item to be linked Part of the file that is to be linked. 


This information is stored in the clipboard and is particularly useful for 
determining the cause of unsuccessful links. 
To establish whether an application is linkable, use the following procedure: 


1. Ensure that Network DDE has been started on your workstation, access 
options have been defined, and the DDE main windows is displayed. 


2. Start the application that you wish to check. 


3. Using the Edit-Copy option, copy some data from your application to the 
clipboard. If your application produces more than one type of data, make 
sure that the data group that you copy is typical of the data that you will 
make available for linking. 
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From the Clipboard Sharing and Network DDE window, select Manage 
Clippings. The Manage Clippings window is displayed as shown in Figure 30 
on page 36. 


To determine if the data in your clipboard is linkable, select Local Clipboard 
Details and select one of the choices in the Names of Saved Clippings list. 
Press Clipping Details. 


You receive one of the following: 
Message informing you that the data in your clipboard is not suitable for 
linking 
Clipboard Details window with details of the linking specifications of the 
data 

Select OK to exit the Clipping Details window. 


Select Close to exit the Manage Clippings window. 








Clipboard Sharing and Network DDE 








Manage Clippings 





Names of saved clippings 


SOSALES.PRN 
S1SALES.PRN 








The clipping NETY/ORK.INI is not suitable for DDE 
linking. 


























Figu 


re 30. Network DDE and Clipboard - Managing Clippings 


Once you have established that the data is suitable for linking, you may then 
proceed to create a DDE link using the following procedure: 
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In the source application: 


. Select the data to be transferred. 


. Use the Edit Copy function of the application to transfer the data and a DDE 


link address to the Clipboard. 


In the destination application: 


. Select a portion of the document to which you want to link, or position the 


cursor at the top-left of the area. 


. Use the Edit Paste Link function of the application to create the link. 


Note: If you are creating a link over the network, first copy the data from the 
source workstation to the Clipboard; then copy the Clipboard to the 
destination workstation. 





Troubleshooting Network DDE Links 


In this section, we look at ways to overcome problems in establishing network 
DDE links. This information is taken from the LAN Server 4.0 README file. 


Identifying Communications Problems 


1. Use the Active Workstations window shown in Figure 31 to verify that the two 
workstations can communicate over the network. This window lists the 
available workstations on the network. If the workstation you want is listed, 
double-click on it to determine its status. If the workstation you want is not 
listed, enter its name, and select the check box to determine its status. 


2. If you still have difficulty establishing a network DDE link, try to establish a 
similar link between the same two applications on the same workstation. If 
you cannot establish the link locally, you cannot establish it over the 
network. If special procedures are required to establish a local link, those 
same procedures are required when you establish a network link. 


3. If you are unable to establish the DDE link locally, try using Excel (or another 
generally successful application) in place of either the source or the 
destination application. If an application does not link with Excel, it probably 
does not link to any application. 
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Select "Check" to see if Clipboard Sharing and 
Network DDE is running on the specified 
workstation. 


Workstations 
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Workstation: OS2REQ01 
Status: Running Clipboard Sharing and Network DDE 







Operating system: OSf2 


















Clipboard Sharing and Network DDE 























Figure 31. Network DDE and Clipboard - Active Workstations 


Identifying Application Problems 


1. Make sure the applications are running and the correct topic (document or 
file) is open in the source application. 


2. Some applications, such as Lotus 1-2-3, require that the document be saved 
and given a file name before the Copy function will create link-format data. 
Also, some applications require you to save the document before you can 
use the Paste Link function. 
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3. Make sure the application has a Paste Link, Paste Special, Link, or Link 
Options menu choice. Some applications, such as Word for OS/2 1.1b, have 
a Full/Short menu choice. The Paste Link (or similar) option may not be 
displayed unless the Full menu choice is selected. 


4. Some applications take a long time (up to two minutes) to establish a DDE 
link. The delay can happen at either the source or destination application. If 
an application appears to hang while creating a link, wait at least two 
minutes before concluding that a failure or timeout has occurred. 


5. If an application prompts you either to keep waiting or to cancel the 
operation, keep waiting a while longer before canceling. You may find that, 
although establishing the link takes a long time, updates to the link behave 
normally and happen relatively quickly. 


Verifying the DDE Link Address 


Use the Clipboard Viewer to make sure the DDE link address is in the Clipboard 
of the destination workstation. If no link-format data exists in the destination 
workstation's Clipboard, check the Clipboard on the source workstation for the 
link-format data, and repeat the Copy command in the source application. If the 
source application's Copy function does not create link-format data, DDE linking 
is not possible. 


Unexpected Results from Established DDE Links 


Once you have successfully established a network DDE link, you may find that 
you do not get the results that you were expecting. The following list details the 
most common causes: 


1. When the destination application is a spreadsheet, simply positioning the 
cursor at the upper left of the desired location in the destination document is 
not sufficient. The entire area to be linked in a destination spreadsheet must 
be selected before using the Paste Link function. For example, if you select 
an area of 4 rows by 5 columns in the source document before using the 
Copy function, then you must select an area of 4 rows by 5 columns in the 
destination document before using the Paste Link function. 


2. Ifa link to a word-processor document seems to lose or garble data, the 
target area in the destination document may be bounded by the size of the 
area that was initially selected in the source document. If you try to insert 
additional text (rather than overwriting existing text) in the destination 
document, the destination application may not accept all of the inserted text, 
and the result may be garbled data. 


Try a local link to a destination word-processor document to determine 
whether an application limitation or a network-related problem causes 
garbled data. 
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Fixing a Corrupted NETGUI.INI File 


If the NETGUI.INI file is damaged, possibly as the result of a trap or abnormal 
end of the LAN Server Administration GUI, the icons may have default titles or 
previously saved information may no longer be available. 


To fix this problem, replace the NETGUI.INI file from a backup copy. The two files 
that store persistent information for the GUI are NETGUI.INI and NETGUI.PDB. 
Use the following steps to replace these files: 


1. Close the LAN Server Administration GUI. 


2. Copy C: IBMLAN NETPROG NETINI.BAK to 
C: IBMLAN NETPROG NETGUL.INI, where C: is the drive on which the LAN 
Server is installed. 


3. Erase NETGUI.PDB. 


4. Reopen the LAN Server Administration GUI. The NETGUI.PDB file will be 
recreated. 
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Chapter 3. OS/2 TCP/AP and TCPBEUI 


This chapter describes the TCP/IP enablement of OS/2 LAN Server 4.0. Based 
on Multiprotocol Transport Networking (MPTN), MPTS is designed to allow any 
NetBIOS application, such as OS/2 LAN Server 4.0 itself, to run over the TCP/IP 
networking protocol. MPTS is provided as part of OS/2 LAN Server 4.0. 


We look at how OS/2 LAN Server 4.0 requester and server workstations can be 
configured to use the IBM TCP/IP 2.0 for OS/2 protocol stack in addition to the 

usual NetBIOS protocol stack. Coexistence between IBM TCP/IP 2.0 for OS/2 

and MPTS is also discussed in this chapter. 


For information on the TCP/IP for DOS Stack Kit, which allows you to run 
NetBIOS over TCP/IP on a DOS LAN Services client, see “DOS LAN Services and 
TCP/IP Coexistence” on page 87. 


-—— Use LAN Server Installation/Configuration Icon! 


You may have noticed that there are both an MPTS icon (on the Desktop) and 
a LAN Server Installation/Configuration icon (in the LAN Services folder). 
When you make updates to MPTS that involve changes to the IBMLAN.INI file, 
it is important that you update LAPS by selecting the LAN Server 
Installation/Configuration icon, and not the MPTS icon. This is because 

MPTS is not LAN Server-specific; that is, MPTS is designed to be used by 
other products as well, and does not update configuration files that are 

unique to a specific product. Although MPTS will update CONFIG.SYS and 
PROTOCOL.INI, it will not update IBMLAN.INI. By selecting the LAN Server 
Installation/Configuration icon, you are ensured of getting the necessary 
updates to CONFIG.SYS, PROTOCOL.INI, and IBMLAN.INI. 


Updates involving TCPBEUI will affect IBMLAN.INI, since the netx=, wrknets=, 
and srvnets= lines may be changed. For this reason, be sure that you use 

the LAN Server Installation/Configuration icon when making TCPBEUI 

changes. 





As a general rule, whenever you are making changes to your LAN 
Requester/LAN Server configuration for any reason, it is best to select the 
LAN Server Installation/Configuration icon. This will ensure the necessary 
changes are made in all configuration files. 











Overview - Why NetBIOS over TCP/IP? 


Native NetBIOS has certain characteristics which limit its use in certain 
communications environments: 


1. The NetBIOS protocol can only be used on a LAN. 

2. The NetBIOS protocol cannot be routed. 

3. The NetBIOS protocol uses single route broadcasts to establish connections. 
A solution to overcome these limitations can be found in RFC 1001 and 1002. 


They describe the standard to implement the IBM NetBIOS services on top of the 
TCP and UDP protocol layers. The LAN Adapter Protocol Support of MPTS 
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provides a TCP/IP protocol stack as well as the new TCPBEUI protocol, which is 
a unique implementation of NetBIOS over TCP/IP. These two components were 
not provided with previous versions of LAPS. 


This capability offers you new opportunities in designing networks. Requesters 
can now access servers through the TCP/IP network. This means that servers 
and requesters can be on different LANs over WANs with connected IP routers, 
such as the IBM6611 router. When OS/2 LAN Server 4.0 is used in conjunction 
with IBM TCP/IP 2.0 for OS/2, you can even share resources from a TCP/IP 
environment, like network printers or mounted drives, to LAN Requester 
workstations. 


A valid OS/2 LAN Server 4.0 design in a TCP/IP environment is shown in 
Figure 32. 
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Figure 32. Multiprotocol Transport Networking with OS/2 LAN Server 4.0 


Since MPTS has a full implementation of the Network Driver Interface 
Specification (NDIS), you may run the NDIS conforming TCP/IP protocol stack 
and the NetBIOS protocol stack on the same physical adapter (but two different 
logical adapters). 
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TCP/IP Protocol and RFC 1001/1002 


TCP/IP was developed under sponsorship of the Defense Advanced Research 
Projects Agency (DARPA). It is widely used and its specification is in the public 
domain. TCP/IP is a general networking protocol, and may be used in any kind 
of network (for example, Ethernet, token-ring, broadcast networks and dedicated 
serial lines). 


While TCP/IP is generally considered to be a transport layer protocol, it is 
composed of several other protocol layers, as follows: 


Internet Protocol (IP) is a general protocol which corresponds roughly to the 
network layer of the ISO reference model. The IP defines the way nodes are 
addressed. All nodes in the network have an IP address, which consists of a 
network number and a station number. 


* TCP is a transport layer, containing several modes of service (for example, 
connection-based virtual circuits and connectionless datagrams). See 
Figure 33 for an overview. 
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Figure 33. Network Protocol Layers Diagram 
The TCP/IP development community designs and publishes new protocol 


specifications by means of a multi-step process. Part of the process is the 
preliminary publication of the proposed standard in a form called Request for 
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Comment (RFC). Once the standard has been accepted, it is still known by its 
RFC number. 


RFCs 1001 and 1002 are specifications which define the relationship between 
TCP/IP and NetBIOS. They define a protocol for use by TCP/IP clients wanting to 
support a NetBIOS communication layer. 


There are several defined classes of NetBIOS over TCP/IP implementations 
specified by the RFCs. The simplest, and the one most widely implemented, is 
the Broadcast Node (B-node) implementation. This covers TCP/IP implemented 
environments which support broadcast and Ethernet, in particular. The 
point-to-point node (P-node) implementation operates in environments where 
there are only point-to-point connections. The mixed node (M-node) 
implementations operates in a mixed environment. 


NetBIOS over TCP/IP (TCPBEUI) 
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NetBIOS over TCP/IP (TCPBEUI) provides a valuable functional enhancement to 
the OS/2 LAN Server 4.0 product by enabling a workstation to be geographically 
isolated from its domain and yet communicate with it transparently. 


Before the release of OS/2 LAN Server 4.0, it was possible to implement a 
configuration of OS/2 LAN Server 3.0 over TCP/IP by installing IBM TCP/IP 2.0 for 
OS/2, and an additional product, IBM NetBIOS 2.0 for TCP/IP, (also an 
implementation of RFC 1001/1002 NetBIOS). However, this older implementation 
was inefficient because of transitions through the code paths between the 

adapter drivers at kernel level (Ring 0) and the application level (Ring 3) IBM 
NetBIOS 2.0 for TCP/IP implementation. 


TCPBEUI is a Ring 0 implementation of NetBIOS for TCP/IP. MPTS also provides 
the TCP/IP protocol stack and the sockets interface necessary to configure 
NetBIOS over TCP/IP, so there is no need to install IBM TCP/IP 2.0 for OS/2 
(unless you wish to use the TCP/IP applications which are provided with this 
product). 


Unlike the older IBM NetBIOS 2.0 for TCP/IP, TCPBEUI does not provides a 
standard (NB30) NetBIOS programming interface, but provides the same, 
advanced, LM10 protocol driver interface also provided by NetBEUI in the pure 
NetBIOS configuration. Figure 35 on page 46 shows this interface. TCPBEUI 
maps NetBIOS API calls into the TCP/IP protocol. NetBIOS over TCP/IP contains 
enhancements over the RFC 1001/1002 standards which improve system 
performance by decreasing broadcast storms, and expanding communications 
over routers and bridges. These enhancements, described in “TCPBEUI 
Enhancements” on page 48, are transparent to NetBIOS applications and do not 
interfere with other B-node implementations that lack similar functions. 


TCPBEUI does not use encapsulation, but rather builds RFC 1001/1002 packets 
and sends them out via UDP and TCP. For example, once a NetBIOS session 
has been established, TCPBEUI will use sockets send commands over a TCP 
connection to send NetBIOS session data. TCPBEUI builds a 4-byte session 
header that precedes the actual user data. Thus, a NetBIOS Chain Send of 
128KB would have an overhead of only 4 bytes. 


TCPBEUI allows peer-to-peer communication over the TCP/IP network with other 
computers which have compatible services. Figure 34 on page 45 gives an 
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overview of the relationship between the NetBIOS, NetBIOS over TCP/IP and 
TCP/IP protocol stacks. 
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Figure 34. NetBIOS Over TCP/IP General View 


Chapter 3. OS/2 TCP/IP and TCPBEUI| 45 


46 








Figure 35. NetBIOS over TCP/IP Structure 
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Figure 35 gives a more detailed view of NetBIOS configured to use both NetBEUI 
and TCPBEUI protocol stacks. ACSNETB.DLL provides a Ring 3 NetBIOS API 
for application programs. Ring 3 NetBIOS commands are sent to NETBIOS.OS2 
for processing. NETBIOS.OS2 provides a Ring 0 NetBIOS API for other device 
drivers to use and also binds to one or more LM10 (LAN Manager 1.0) protocol 
drivers. 


Support for NetBIOS over TCP/IP can easily be added to the existing NetBIOS 
structure since NETBIOS.OS2 supports one or more LM10 protocol drivers. It is 
provided by having NETBIOS.OS2 bind to TCPBEUI.OS2. 


Finally, data transfer is handled by a MAC device driver, for example, the 
IBMTOK.OS2 device driver. 


The Multiprotocol Transport Services (MPTS) shipped with OS/2 LAN Server 4.0 
provides the capability of configuring LAN Requester (or LAN Server) 
workstations with both NetBEUI and TCPBEUI on the same network interface 
card. This dual protocol stack configuration will allow local sessions to continue 
running with NetBEUI performance while also providing wide area network 


connectivity with NetBIOS over TCP/IP. 
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TCPBEUI and IBM TCP/IP 2.0 for OS/2 Coexistence 


Figure 36 on page 48 shows an example scenario with both TCP/IP and NetBIOS 
protocols being used, and IBM TCP/IP 2.0 for OS/2 installed on a workstation. In 
this example, the workstation is able to access the OS/2 LAN Server 4.0 
resources on the local LAN segment via NetBIOS, the OS/2 LAN Server 4.0 
resources on the remote LAN segment across the IP network via TCPBEUI and, 
in addition, is able to use the TCP/IP applications provided by IBM TCP/IP 2.0 for 
OS/2 to access other TCP/IP resources via the native TCP/IP protocol. 


MPTS provides the TCP/IP protocol capability with or without IBM TCP/IP 2.0 for 
OS/2 installed, but provides only a limited set of TCP/IP applications. These are: 
IFCONFIG 
ROUTE 
* ARP 
PING 
* NETSTAT 
HOST 
HOSTNAME 
If you wish to use the full set of applications and services provided by IBM 
TCP/IP 2.0 for OS/2, it is recommended that this is installed before you install 
MPTS If IBM TCP/IP 2.0 for OS/2 is already installed, installing MPTS will 


replace the existing TCP/IP device drivers, removing the following lines from 
CONFIG.SYS: 


DEVICE=x: \IBMCOM\ PROTOCOL\ INET. SYS 
DEVICE=x: \IBMCOM\PROTOCOL\IFNDIS.SYS 
RUN=x: \TCPIP\BIN\CNTRL. EXE 













































































If you do install IBM TCP/IP 2.0 for OS/2 after having installed MPTS make sure 
that you choose not to install the LAN Adapter and Protocol Support, as this will 
overwrite the MPTS and TCPBEUI code. You must then reboot and run the 
MPTS configuration again to ensure that your system is set up correctly. 
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Figure 36. NetBIOS and TCP/IP Coexistence 





TCPBEUI Enhancements 


Enhancements to NetBIOS over TCP/IP, or TCPBEUI, include the addition of 
routing extensions and a name cache. This section discusses these topics and 
also gives you information on how to use an existing Domain Name Server 
(DNS) in a TCPBEUI environment. 


TCPBEUI Fixes 





To take full advantage of these enhancements, get the latest TCPBEUI fixes 
from your IBM customer service representative. 





Routing Extensions 


Three of the enhancements to TCPBEUI are in the form of routing extensions. 
These extensions allow communication between networks and over IP routers 
and bridges. The routing extensions are: 


1. Names file. A names file consists of NetBIOS name and IP address pairs. 
NetBIOS over TCP/IP will conduct a prefix search of the names file before 
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broadcasting on the network. The prefix match succeeds if the entry in the 
names file matches the given name, up to the length of the entry. The first 
match is used, therefore, the order in which NetBIOS names are listed in the 
names file is important. 








Tr 


To enable this routing extension, set the NAMESFILE parameter in the TCPB 


























section of the PROTOCOL.INI to a nonzero integer that represents the 
number of names file entries. 


2. Domain Name Server (DNS). A network administrator can maintain NetBIOS 
name and IP address pairs ina DNS. If a name query fails, NetBIOS over 
TCP/IP can append the NetBIOS Domain Scope String to the encoded 
NetBIOS name and issue a request to the DNS to look up an IP address for 
that NetBIOS name. The Domain Scope String is defined by the 
PROTOCOL.INI parameter DOMATNSCOPE. 

















For more information on how to set up the DNS with the NetBIOS names, see 
“Storing NetBIOS Names on the Domain Name Server’ on page 50. 


3. Broadcast file. A broadcast file contains a list of host names, host 
addresses, or directed broadcast addresses. It is read at startup and each 
valid address is added to the set of destination addresses for broadcast 
packets. Remote nodes included in the broadcast file are then treated as if 
they were on the local network. Use of a broadcast file has the effect of 
extending a node's broadcast domain to its own subnet plus any other 
subnets listed in the broadcast file. A maximum of 32 broadcast file entries 
are supported, each of which could include additional subnets, thus 
extending the node's broadcast domain. 


If your routers support directed broadcasts (that is, you can ping the 
broadcast address of a distant IP subnet, and get back a response from all 
the stations on that subnet), then you can place the broadcast address for 
each subnet in the server's broadcast file. Also enable the TCPBEUI name 
cache described in “Name Cache and Name Discovery Algorithm.” This 
greatly reduces broadcast traffic and eases administration. (The clients still 
need to know the IP address and NetBIOS name of each server and peer 
server.) 


Name Cache and Name Discovery Algorithm 


Another enhancement NetBIOS over TCP/IP provides is a name cache for storing 
remote names that have been discovered. Since TCPBEUI uses broadcasting as 
a mechanism for name discovery, by checking the cache first, broadcast traffic 
can be reduced. This cache is enabled by setting the NAMECACHE parameter in the 
TCPBEUI section of the PROTOCOL.INI to a nonzero integer that represents the 
number of names stored in the directory (NAMECACHE=xx). 









































The information in the remote name cache (or directory) is also stored on disk 
and periodically updated. When the system is restarted, this information can be 
preloaded into the cache at bootup time. Preloading can reduce the amount of 
broadcast frames on the network since NetBIOS will not have to rediscover 
names for remote workstations. To preload the remote names cache, set 
PRELOADCACHE=YES in the TCPBEUT section of the PROTOCOL. INI. 



































When NetBIOS over TCP/IP is searching for a name, the following name 
discovery algorithm is used: 
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1. Check the local name cache first. 
2. If not found, check the local names file. 


3. Next, issue GetHostByName() to the Domain Name Server. The 
tcpip etc hosts file is checked if the GetHostByName to the DNS fails. 


4. Finally, issue a broadcast using the broadcast file's entries. 


It is recommended that when running NetBIOS over TCP/IP in a wide area 
network (WAN), you should turn name caching on at the server (NAMECACHE=100). 
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In a larger network where a DNS already exists, you can use the DNS database 

to store NetBIOS name and IP address pairs, thereby eliminating the need for 
maintaining a broadcast file or names file on each client. In each client 
PROTOCOL.INI file, you must only ensure that the DOMATNSCOPE parameter is set 
to the TCP/IP domain name. TCPBEUI will then know to search that domain's 
DNS for the IP address of the requested server. 

















Notes: 


1. The solution described in this section assumes that the LAN Server is 
already set up as a TCP/IP machine with a host name/IP address pair that is 
registered in the DNS database. 


2. If you do not have a DNS, you can set up the local node's hosts file 
( tcpip etc hosts) in the same way we describe here. That is, the NetBIOS 
names must be encoded in the hosts file just as they must be in the DNS. 
TCPBEUI will first look for the requested server IP address in the DNS; if one 
does not exist or the address is not specified in the DNS, TCPBEUI checks 
for the local hosts file. 


The LAN Servers' NetBIOS names must be added to the DNS database in an 
encoded format. The encoding is necessary because NetBIOS names are 16 
bytes of any bit pattern and a TCP/IP DNS only accepts host names in the 
character set A to Zand 0 to 9. 





For example, if you have specified DOMAINSCOPE=austin.ibm.com in the 
PROTOCOL.INI file and the NetBIOS name you have requested is not found in 

the local names cache or the local names file, then a sockets 

GetHostByName (netbios_name.austin.ibm.com) call will be made. TCPBEUI 
translates the 16-byte NetBIOS name into a 32-byte reversible, half-ASCII biased 
encoded format, such as: 

















GetHostByName (GCHCGJUGDGFCACACACACACACACACACACA. austin. ibm.com) 


and sends it to the DNS. If the DNS knows this name, it sends back the IP 
address to TCPBEUI. For this to work, the administrator must store the NetBIOS 
names in the DNS in the encoded format. 





How do you encode NetBIOS names and store them in the DNS database? You 
must encode the 16 byte name into a 32-byte string using the MAPNAME utility, 
which is located in the APPLETS directory of MPTS diskette 3 (MPTSAPLT.ZIP). 
Then, you store the names in the DNS database so that they point back to the 
original host name, where the TCP/IP address is already listed. We will take you 
through an example on how to do this. 
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For each server, there will be at least three entries in the DNS database in 

addition to the initial host name entry. (Remember, we are assuming that the 

LAN Server is already set up as a TCP/IP host, with a host name/IP address pair 
that is registered in the DNS database.) The three entries are necessary 

because LAN Server issues a NetBIOS NCB.AddName call three times, using the 
computername specified in the IBMLAN.INI file and ending each with a unique hex 
value as the sixteenth byte. The hex values used as the sixteenth byte are 0x20 
(blank or null), 0x00, and Ox03. If the server is a domain controller, there must 

be a fourth entry, the encoded domain name with the sixteenth byte of 0x00. 


Let's say that we have a DNS already set up on our network. We have installed 
LAN Server 4.0 on the domain controller and one additional server. Both 
machines also have TCP/IP for OS/2 installed, and their host names are 
registered in the DNS database. We want to configure for TCPBEUI so that 
clients can access servers across our IP router without requiring a broadcast file 
or names file at each client. To do this, we will take advantage of the DNS, and 
add the appropriate DOMAITNSCOPE entry to each client's PROTOCOL.INI file. 

















In this example, our domain name is ITSCAUS, and our two servers are 
configured as follows: 


Domain controller Computername: ITSCSV00 
TCP/IP host name: ITSCWKOO 


Additional server Computername: ITSCSV01 
TCP/IP host name: ITSCWK01 


Note: The computername refers to the IBMLAN.INI parameter. This is also 
referred to as the server name or machine ID. 


Here's an extract from our DNS database before we add the encoded NetBIOS 
names: 











ITSCWKOO 86400 IN A 129.35.144.210 
IN HINFO DC HOST NAME 

















ITSCWKO1 86400 IN A 129.35.144.211 
IN HINFO AS HOST NAME 











, 











Figure 37. Sample DNS Database File Before Adding Encoded NetBIOS Names. The 
TCP/IP host names are listed with the workstation IP addresses. 


The HINFO keyword specifies comment information. In this case, we have 
indicated that ITSCWKOO is the TCP/IP host name for the domain controller, and 
ITSCWKO01 is the host name for the additional server. TCP/IP looks up the host 
name in the DNS database and finds the actual IP address. 


Now we want to use TCPBEUI and take advantage of the DNS database. To do 
this, we must encode the server NetBIOS names using the MAPNAME utility. 
Typing MAPNAME by itself will give you help on how to use the command. The 
utility converts NetBIOS names to RFC-encoded names and vice versa. Using 
our example, the following steps show you how to encode your server NetBIOS 
names. 
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MAPNAME Requires Uppercase NetBIOS Name 


When using MAPNAME, be sure to type the NetBIOS computername in 


uppercase letters, as this is a case sensitive utility. If you type the 


computername in lowercase, the output will be incorrect. 





1. Use MAPNAME with the /RB parameters to specify that you want the output to be 


in RFC format and padded with blanks for up to 16 characters. 





MAPNAME ITSCSV0O0O /RB 











The following 32-byte encoded name is displayed: 








RFC name: EJFEFDEDFDFGDADACACACACACACACACA 


























This is the first of the four encoded names you need for the domain 
controller. Here, the sixteenth byte, CA, is null (0x20). The following 
command would have given us the same result, but since null characters are 
the default, the L20 is unnecessary. 


MAPNAME ITSCSVOO /RBL20 








2. This time, also use the L parameter to specify that you want the last 


character of the output to be 0x00, as follows: 





MAPNAME ITSCSV00 /RBLOO 











The result is: 








RFC name: EJFEFDEDFDFGDADACACACACACACACAAA 
AA is hex 0x00. 


























3. Again, use the L parameter to specify the last character of the output to be 


0x03, as follows: 





MAPNAME ITSCSV00 /RBLO3 











You receive this output: 








RFC name: EJFEFDEDFDFGDADACACACACACACACAAD 
AD is hex 0x03. 





























4. Because this is the domain controller, you must also specify the encoded 


domain name with the sixteenth byte of 0x00, as follows: 





MAPNAME ITSCAUS /RBLOO 











The encoded name is: 








RFC name: EJFEFDEDFDFGDADACACACACACACACAAA 


























5. Now we go through the first three steps for the additional server, ITSCSV01, 


to get the following output. (Do not encode the domain name for additional 
servers.) 





MAPNAME ITSCSV0O1 /RB 
RFC name: EJFEFDEDFDFGDAI 














O 


BCACACACACACACACA 








MAPNAME ITSCSV01 /RBLOO 
RFC name: EJFEFDEDFDFGDADBCACACACACACACAAA 



































MAPNAME ITSCSV01 /RBLO3 
RFC name: EJFEFDEDFDFGDADBCACACACACACACAAD 


















































6. Edit the DNS database to add the entries for the domain controller and 


additional server. Use the DNS CNAME keyword to point back to the host 
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name entry for the machine where the actual IP address is already specified. 
In other words, the encoded names we have generated are aliases for the 
host names ITSCWKOO and ITSCWKO1. You cannot have two entries pointing 
to the same IP address, so you must use the CNAME keyword to create 
aliases. 


The following example shows how our DNS database file looks after adding 
the NetBIOS encoded names. Again, we use HINFO to designate comments. 





ITSCWKOO 86400 IN A 129.35.144.210 
IN HINFO DC HOST NAME 














T~e 





iJ FEFDEDFDFGDADACACACACACACACACA 86400 IN CNAME ITSCWKOO 
IN HINFO ITSCSVOO (0x20 in byte 16) 




















Tose 





iJ FEF DEDFDF.GDADACACACACACACACAAA 86400 IN CNAME TSCWKOO 
IN HINFO ITSCSVOO (0x00 in byte 16) 























To~e 


iJ FEF DEDFDFGDADACACACACACACACAAD 86400 IN CNAME TSCWKOO 
IN HINFO ITSCSVOO (0x03 in byte 16) 




































































Tose 





iJ FEF DEDFDFGDADACACACACACACACAAA 86400 IN CNAME TSCWKOO 
IN HINFO ITSCAUS (0x00 in bytle 16) 




















ITSCWKO1 86400 IN A 129.35.144.211 
IN HINFO AS HOST NAME 














Tose 


iJ FEF DEDFDFGDADBCACACACACACACACA 86400 IN CNAME TSCWKO1 
IN HINFO ITSCSV0O1 (0x20 in byte 16) 




















TT ~e 





iJ FEFDEDFDFGDAI 


O 


BCACACACACACACAAA 86400 IN CNAME TSCWKO1 
IN HINFO ITSCSV0O1 (0x00 in byte 16) 























Tose 


















































iJ FEFDEDFDFGDADBCACACACACACACAAD 86400 IN CNAME TSCWKO1 
IN HINFO ITSCSVO01 (0x03 in byte 16) 















































Figure 38. Sample DNS Database File After Adding Encoded NetBIOS Names. The 
encoded NetBIOS names point back to the TCP/IP host names (using CNAME), where the 
workstation IP addresses are specified. 


For the domain controller (ITSCSV00), there are four encoded entries, three 
for the server name (computername) and one for the domain name 
(ITSCAUS). For the additional server (ITSCSV01), there are three encoded 
entries for the server name. The encoded entries are all aliases that point 
back to the host names. 





7. On your clients, be sure that you set the DOMAINSCOPE parameter to point to 
the correct TCP/IP domain, for example, DOMATNSCOPE=austin.ibm.com. This 
enables TCPBEUI to use the DNS to find the NetBIOS name/IP address pairs, 
eliminating the need for a broadcast file or names file at each client. 





























For further information on the Domain Name Server, please refer to the /BM 
TCP/IP Version 2.0 for OS/2 Domain Name Server Guide. 
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Installing MPTS-TCPBEUI 


OS/2 LAN Server 4.0 can operate with either NetBIOS or TCPBEUI (or both) 
bound to its LAN adapters. This section gives information on configuring OS/2 
LAN Server 4.0 in a TCPBEUI environment. 


1. TCPBEUI is installed as part of MPTS, which itself will install automatically as 
part of the LAN Server/Requester installation process. With the first LAN 
Requester diskette in a diskette drive, the installation command is: 


--INSTALL- - ------ -------------------------------------------------- 
-/NS- 





Note: If you do not want MPTS to sniff for the installed LAN adapter, issue 
the INSTALL command with the /NS parameter. 


2. At the Multiprotocol Transport Services-Logo window select the OK button. 
3. At the Multiprotocol Transport Services window select the Configure button. 


Note: If you have not yet installed MPTS you will need to select Install 
before you configure. 


4. Configuring LAN Adapter and Protocol Support 


a. At the Configure window which is shown in Figure 39, select LAN 
adapters and protocols. Then select Configure. 


© Configure 
Select an item below, then select Configure. Once you return to 
this panel you can select another item or select Close to save your 


configuration. 


Adapters and Protocols Status 





Hot configured 


Migrate a CM 1.3 .CFG file 


socket/MPTS transport access 
2 JCP E Sopgel access Not configured 
SLBIOS SOCke: abcess Not configured 


Non-native networking 
un T CRAP apclicatong aver NetBhhos Not configured 


Figure 39. MPTS Configure Window 





The LAPS Configuration window will be opened which is shown in 
Figure 40 on page 55. 


54 inside OS/2 LAN Server 4.0 


LAPS Canfiguration 


Select a network adapter and then select protacols to go with it. 
_Hetwork Adapters 


IBM SMP Token-Ring Network Adapter % | IBM OS/2 NETBIOS 
JBM Streamer Family Adapter (IBMMPC. M Netware Requester Supp 
BM Token Ring Network 16/4 Adapter M TCP/IP 


-Current Configuration 


To edit driver parameters, select anitem below and — complete. 
then select Edit. 


IBM Token-Ring Network Adapter 
Q - IBM TCPYIP 


he BY Sz HETBIOS OVER TCE 


Change number... 





Figure 40. MPTS-LAPS Configuration Window 


From the Network Adapters list select the network adapter being 
installed in your workstation. Then select the following network 
protocols from the Protocols list: 


* TCP/IP (TCP/IP protocol stack) 
IBM OS/2 NetBIOS OVER TCP/IP (TCPBEUI) 


Figure 40 shows both the TCP/IP and NetBIOS over TCP/IP (TCPBEUI) 
protocols selected. You may additionally select the IBM OS/2 NetBIOS 
protocol if you need to have native NetBIOS available. 


b. You may now edit the standard settings for IBM OS/2 NetBIOS OVER 
TCP/IP by double-clicking on the protocol driver's name in the Current 
Configuration list. This may not be needed unless you are running large 
networks. The following restrictions apply to this first release of 
TCPBEUI: 


+ A maximum of 254 sessions is supported. 


In the first release of TCPBEUI, there is no name sharing code 
implemented as there is in NetBIOS. For OS/2 LAN Server 4.0, this 
means that only one netx statement is valid in the 

IBMLAN IBMLAN.INI file. 


netl = tcpbeuis$,0,LM10,102,175,14 





Note: The net1 example shown above contains default configuration 
values as provided by OS/2 LAN Server 4.0 when TCPBEUI is 
configured. 


However, TCPBEUI does support any and all LAN adapters that have 
been configured for TCP/IP. This is because TCPBEUI binds with the 
TCP/IP protocol stack, which itself may be bound to a number of 
adapters. When TCPBEUI issues a send to TCP/IP, TCP/IP will choose 
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the adapter on which to send the frame. Likewise, when a RFC 
1001/1002 frame is received by any adapter, TCP/IP will pass this frame 
up to TCPBEUI. So, TCPBEUI supports any and all adapters configured 
for TCP/IP, but only supports 254 NetBIOS sessions because of the lack 
of name sharing code. 


c. After having double-clicked on the IBM OS/2 NetBIOS OVER TCP/IP 


protocol driver's name in the Current Configuration list, you will get the 
NetBIOS over TCP/IP window shown in Figure 41. 





Select an optional item below, then select Canfigure. 
| Onee you return to this panel You can select another 
| optional item or select Close to return to the LAPS 

_ Configuration window. 





Options 
w Driver parameters 


v7 Names list i 


gz Broadcast list 


Figure 41. NetBIOS Over TCP/IP Window 
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d. Select Drivers parameters radio button and click on the Configure button. 


You may leave the settings as they are, or adapt these to your 
environment. For example, increase the number of NetBIOS sessions, 
commands, and names if you have a large number of users to be 
supported by OS/2 LAN Server 4.0 using the TCPBEUI protocol. 


. Use the Names list to edit your NetBIOS over TCP/IP names list. The 


names list contains pairs of NetBIOS name prefixes and host names or 
IP addresses. Whenever a name query is required, this list is searched 
for a matching entry. A hit found in the list removes the need for the 
name query broadcast. The names list is saved in the 
\IBMCOM\RFCNAMES.LST file. 


The NetBIOS name prefix field is effectively the computername (specified in 
IBMLAN.INI) of the remote workstation. It should be in standard NetBIOS 
name format, which is a string containing up to 16 bytes. The Host name 

or IP address field specifies the TCP/IP host name or the IP address of 

the remote workstation. 


An example is shown in Figure 42 on page 57. 





Figure 42. NetBIOS Over TCP/IP Names List Window 


f. Use the Broadcast list if you wish to extend the TCP/IP broadcast domain 
of the local workstation. It contains a list of host names and IP 
addresses, (which may be machine or subnet addresses) which will be 
included, in addition to the subnet of the local workstation, whenever a 
broadcast is sent. 


An example is shown in Figure 43. 





Figure 43. NetBIOS Over TCP/IP Broadcast List Window 


g. At the LAPS Configuration window, select OK to continue configuring 
LAPS. The Configure window is displayed showing information that 
TCP/IP Socket Access must be configured. See Figure 44 on page 58. 
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— Configure 


Select an item below, then select Configure. Once you return to 
this panel you can select another item or select Close to save your 
configuration. 


Adapters and Protocols Status 





(2L4N adapters and protocols Configured 
Migrate a CM 1.3 .CFG file 


socket/MPTS transport access 
TCP/IP Socket access Must configure 
eBiCS Secke: access Not configured 


Non-native networking 
un TORS apclostons over NelbiOs Not configured 





Figure 44. MPTS Configure Window After TCPBEUI Configuration 


5. Use Socket/MPTS transport access to select the protocols that you may use. 
The selections being made notify Socket/MPTS to initialize the protocol 
services required. 


a. Select TCP/IP Socket Access and then select Configure. The TCP/IP 
Configuration window will be opened (which is shown in Figure 45). 


TCBIP Configuration 


Select one or more items below, then select Configure. When you 
are finished, select Close to save your configuration. 


Status 
® Network interface parameters Not configured 
gy Routing informatian Not configured 


Z Domain name services Not configured 


Cancel 





Figure 45. TCP/IP Configuration Window 


Select the Network interface parameters radio button and then Configure 
The Configure TCP/IP Network Interface Parameters window is displayed: 
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Configure TCP/IP Network Interface Parameters 
Select LAN adapte 
AN Adapter 1 - NON-ACTIVE Enable 
[LAN Adapter 2 - NON-ACTIVE 
AN Adapter 3 - NON-ACTIVE / Disable 


Routing metric count: © 


(default is all fields off) 


allrs Single route broadcast =. niers = Trailer encapsulation 


bridge Disable routing icmpred 


snap _ Disable ext. SNAP -canonical “Canonical address 





Figure 46. Configure TCP/IP Network Interface Parameters Window 
Configure your TCP/IP environment accordingly and save your entries by 
pressing the Save button. Then press the OK button. 
b. If needed, configure Routing Information as appropriate. 
c. If needed, configure Domain name services as appropriate. 
d. Select Close to finish configuring TCP/IP. 


If you did not configure Routing Information and Domain name services in 
the steps before you may now select Close at the Configure window to finish 
LAPS configuration. Otherwise proceed with the following steps: 


6. Configure NetBIOS Socket Access if you want to customize non-native 
networking. 


7. Configure Run TCP/IP applications over NetBIOS as appropriate. 
8. To close LAPS configuration, select Exit at the Multiprotocol Transport 
Services window. Confirm changes to CONFIG.SYS. 


Now you can implement a OS/2 LAN Server 4.0 environment running NetBIOS 
over TCP/IP. See “TCPBEUI Enhancements” on page 48 and the following 
sections for important considerations in this environment. 


NetBIOS Considerations 
Using TCPBEUI, the following must be considered: 


* An application using TCPBEUI cannot communicate with another application 
using native NetBIOS. Even if applications are written to the NetBIOS 
programming interface, TCP/IP protocol stacks cannot talk with NetBIOS 
protocol stacks. A partner must use the same communication protocol stack. 
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Performance Considerations 


The performance when using TCPBEUI is generally slower than using native 
NetBIOS due to the additional overhead of mapping NetBIOS API calls to TCP/IP 
(However, using OS/2 LAN Server 4.0 over TCPBEUI is significantly faster than 
using OS/2 LAN Server 3.0 with IBM NetBIOS 2.0 for TCP/IP, because there is no 
longer a transition overhead from Ring 3 to Ring 0). The performance difference 
can range widely depending on the environment. Some environmental factors 
that can affect performance are the type of client (OS/2 or DOS), the server CPU 
workload, the type of network operations being performed, the network media, 
network congestion, and communication line speeds. We've observed the 
performance of NetBIOS over TCP/IP being anywhere from 10% slower to as 
much as 4 times slower than NetBEUI. 


One of the environments in which performance tests were conducted was a 
medium-sized LAN on 16Mbps Token Ring with no WAN connections. We rana 
set of industry standard business applications on TCPBEUI clients and again on 
OS/2 NetBEUI clients. In this environment, NetBIOS over TCP/IP was 20% 
slower than NetBEUI. The performance of DOS NetBIOS over TCP/IP clients was 
significantly less than that of the OS/2 clients. 


Database applications generally use small records when accessing shared 
databases residing on the server. Often these small records are retrieved from 
the file system cache with no physical disk access being required. The 
performance of this type of application on NetBIOS over TCP/IP may be 
noticeably slower than if the application were run using NetBEUI. However, if 
the number of database accesses of this type in performing a typical operation is 
in the order of hundreds, not thousands, the user may not notice a difference in 
performance in the two protocols. 


It may be necessary to periodically update client applications or other files by 
copying them from the server disk. DCDB replication from a domain controller 

to a remote additional server also generates I/O operations sometimes known as 
file transfers. This type of file I/O activity over a network will show little or no 
performance difference between NetBEUI and NetBIOS over TCP/IP due to 
protocol characteristics. One should be aware, however, that most WAN 
connections today are made over relatively low-speed communication lines 

when compared with a LAN speed of 4 to 16 Mbps. File transfer operations over 
WAN communication lines will probably be slower than over LANs but most 

likely not due to the network protocol. 


Tuning Considerations for TCPBEUI 
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If you're using NetBIOS over TCP/IP in a token-ring environment, file transfer 
performance might be improved by increasing the maximum transmissible unit 
(MTU) size. We have seen up to a 20 percent increase in performance of large 
file transfers by using an 8 KB packet instead of the default 1500 bytes. The 
default of 1500 was chosen because of Ethernet's packet size limitation and 
prevalence in TCP/IP environments. The MTU size can be changed with the 
IFCONFIG command in TCP/IP‘s SETUP.CMD. Set the MTU size to the desired 
packet size plus 40 bytes, the maximum TCP/IP header size. The desired packet 
size should be a multiple of 2048. Your network adapter must be configured to 
support transmission of buffers that are at least the size specified for the MTU. 
On an IBM 16/4 Token-Ring Adapter, this would be accomplished by setting the 
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XMITBUFSIZE parameter in the token-ring section of the PROTOCOL.INI file. 
Check your network interface card documentation for information on configuring 
your adapter. 


It is also recommended that you use the INETCFG command to change the 
default keepalive value from the default of 120 minutes to a lower value, for 
example: 


inetcfg keepalive=10 


The reason for this is that a TCPBEUI server is not informed of a TCP/IP 
connection breaking for a period of two hours. Thus, a TCPBEUI server could 
accumulate a large number of ghost sessions. By issuing the inetcfg 
keepalive=10 command, TCP/IP will inform TCPBEUI after 10 minutes that a 
TCP/IP connection is broken (that is, a remote client has gone down). 


If you are experiencing difficulties accessing a remote server over a slow WAN 
connection, try gradually increasing the NETBIOSTIMEOUT parameter in 
PROTOCOL.INI. 


When using both NetBEUI (for LAN access) and TCPBEUI (for WAN access), it is 

best to have net1=netbeui and net2=tcpbeui, as shown in Figure 50 on page 63. 
In this dual protocol environment, it is recommended that you decrease 
NETBIOSRETRIES to 2 or 3 (from the current default of 8). Also, be aware that if 

the NETBIOSTIMEOUT parameter is set too high, some local LAN functions, such 

as logon and NET USE, may take significantly longer. 





Installing a Server with MPTS-TCPBEUI 


Having followed the steps described in “Installing MPTS-TCPBEUI” on page 54, it 
is simple to install a server running in a TCPBEUI environment. The OS/2 LAN 
Server 4.0 installation program checks for an LM10 interface (NetBEUI or 
TCPBEUI) and does not differentiate between these two possible 
implementations. 


Configuring Native NetBIOS and TCPBEUI on One LAN Adapter 


You can run native NetBIOS and TCPBEUI protocol stack on the same physical 
adapter (two logical adapters) since MPTS has a full implementation of the NDIS 
interface. This allows you to use NetBEUI to access servers in your LAN 
environment, and TCPBEUI to access servers in your WAN environment. Be 
sure to understand the performance and tuning considerations in this 
environment, as discussed previously. 


When selecting protocols, install logical adapter 0 with IBM OS/2 NETBIOS 
(NetBEUI) and IBM TCP/IP and logical adapter 1 with IBM NETBIOS OVER TCP/IP 
(TCPBEUI). At the LAPS Configuration window, your current configuration has to 
be adapted as follows, assuming one IBM Token-Ring adapter is present: 
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BM Token-Ring Network Adapter 
0 - IBM O0S/2 NETBIOS 

0 - IBM IEEE 802.2 
0 - IBM TCP/IP 

1 - IBM OS/2 NETBIOS OVER TCP/IP 





















































Figure 47. LAPS Configuration Panel. This shows one token-ring adapter being bound to 
NetBIOS, IBM IEEE 802.2, and TCPBEUI. Although NetBIOS over TCP/IP must be on 
different logical adapter from NetBEUI, TCP/IP can reside on the same logical adapter as 
NetBEUI. 


Note that the numbers of the protocol drivers have to be set differently although 
only one physical LAN adapter is present. 


The following changes were made to the CONFIG.SYS file by MPTS: 





CALL=C: \IBMCOM\PROTOCOL\NETBIND. EXE 
UN=C : \IBMCOM\LANMSGEX.EXE SET ETC=C:\MPTN\ETC 
EVICE=C: \MPTN\PROTOCOL\MPTN. SYS 

EVICE=C: \MPTN\PROTOCOL\LIPC.SYS 

EVICE=C: \MPTN\PROTOCOL\INET.SYS 

EVICE=C: \MPTN\PROTOCOL\IFNDIS.SYS 

UN=C: \MPTN\BIN\CNTRL.EXE /P mptn_os$ mptn_ins 
ALL=C:\OS2\CMD.EXE /Q /C C:\MPTN\BIN\MPTSTART.CMD 
UN=C : \IBMCOM\ PROTOCOL\NBTCP. EXE 
EVICE=C: \IBMCOM\PROTOCOL\TCPBEUI .OS2 
EVICE=C: \IBMCOM\PROTOCOL\NETBEUI .OS2 
EVICE=C: \ IBMLAN\NETPROG\RDRHELP. 200 
EVICE=C: \IBMCOM\PROTOCOL\NETBIOS.OS2 
UN=C : \IBMCOM\ PROTOCOL\LANDLL. EXE 
EVICE=C: \IBMCOM\MACS\IBMTOK.0S2 
EVICE=C: \IBMCOM\PROTOCOL\LANDD.OS2 
EVICE=C: \IBMCOM\PROTOCOL\LANDLLDD.OS2 SET 
HOSTNAME=ITSCWK3 .AUSTIN. IBM.COM 
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Figure 48. CONFIG.SYS (Extract). This shows one token-ring adapter being bound to 
NetBIOS, IBM IEEE 802.2, and TCPBEUI. 


When you restart your workstation after LAPS configuration, the following LAN 
device driver messages are displayed: 





IBM OS/2 LANMSGDD [09/09/94] 2.01 is loaded and operational. 
IBM OS/2 LAN Protocol Manager IBM - OS/2 Socket/MPTS Common Transport Semantics 
IBM OS/2 NETBEUI 2.20.1 NETBEUI: Using a 32-bit data segment. 
IBM OS/2 TCPBEUI 1.00 TCPBEUI: Using a 32-bit data segment. 

IBM OS/2 NETBIOS 4.0 

Adapter 0 has 225 NCBs, 130 sessions, and 21 names available to NI 
Adapter 1 has 225 NCBs, 130 sessions, and 21 names available to NI 
NETBIOS 4.0 is loaded and operational. 

IBM OS/2 LANDD [09/09/94] 2.20.12 

IBM OS/2 LANDLLDD 2.01 

IBM OS/2 LANDLLDD is loaded and operational. 
































TBIOS applications. 
TBIOS applications. 




















Figure 49 (Part 1 of 2). LANTRAN.LOG 
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IBM - IBM Token-Ring Network Driver, Version V.2.02 

IBM LANVDD is loaded and operational. 

IBM OS/2 LAN Netbind IBM Token-Ring adapter data rate is 4 mbps. 
IBM LANDD is accessing IBM 802.5 LAN Interface. 

Adapter 0 was initialized and opened successfully. 

Adapter 0 is using node address 10005A6F3ADA. 

IBM LANDD was successfully bound to MAC: IBMTOK_nif->VECTOR. 
IBM - OS/2 Socket/MPTS Local IPC Service Driver 

IBM - OS/2 Socket/MPTS INET Service Driver 

IBM - OS/2 Socket/MPTS IFNDIS Protocol Driver 




















Figure 49 (Part 2 of 2). LANTRAN.LOG. This shows one token-ring adapter being 
bound to NetBIOS, IBM IEEE 802.2, and TCPBEUI. 


OS/2 LAN Server 4.0 handles this configuration as if there were two adapters 
present. Therefore, two netx entries will be made in IBMLAN.INI: 


[networks] 





NETBEUIS,0,LM10,102,175,14 
tcpbeui$,1,LM10,102,175,14 








net1l 
net2 





[requester] 





wrknets = NET1,NET2 





[server] 

















srvnets = NET1,NET2 














Figure 50. IBMLAN.INI (Extract). This shows both NetBIOS and TCPBEUI being bound to 
a single LAN adapter. 


Removing the TCPBEUI Configuration 


When you are removing the TCPBEUI configuration from Multiprotocol Transport 
Services, you must first remove TCP/IP Socket Access at the Configure panel 
before proceeding to the LAPS configuration panel and removing the IBM TCP/IP 
protocol and the IBM OS/2 NetBIOS over TCP/IP protocol. 


If the removal is not performed in this manner, the protocols will be removed 
from the PROTOCOL.INI file, but the MPTN BIN MPTCONFG.INI file will not be 
updated properly. This will result in invalid device drivers being added to the 
CONFIG.SYS file. 





-— Reconfiguring Protocols 


When reconfiguring protocols that affect OS/2 LAN Server 4.0, you should 
reconfigure MPTS through the LAN Server Installation/Configuration icon 
(which resides in the LAN Services folder) instead of the MPTS Desktop icon 
or application. This will give you the opportunity of changing which of the 
available logical adapters are to be used by the LAN requester or server, and 
will ensure that the IBMLAN.INI file is updated as well as the MPTS 
configuration. 
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Chapter 4. DOS LAN Services and TCP/IP for DOS 


DOS LAN Services is the component of OS/2 LAN Server 4.0 that provides LAN 
connectivity for users of workstations running DOS in the same way that DOS 
LAN Requester has for previous versions of LAN Server. There are some 
significant enhancements in DOS LAN Services. 


DOS LAN Services may function in a DOS environment with or without Windows. 
As was the case with DOS LAN Requester, when implemented on a system 
running DOS and Windows, you may access network resources through the 
Windows graphical user interface. However, with DOS LAN Services, users are 
now provided with a LAN Server graphical user interface, independent of 
Windows. This replaces the character-based DOS LAN Requester menu system. 


In addition, the more experienced user or LAN administrator may perform 
network tasks or automate repetitive functions via NET commands from the DOS 
command line or via DOS batch files. Using NET ADMIN, an administrator at a 
DOS LAN Services workstation can manage servers remotely using the 
command line interface. 
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Figure 51. DOS LAN Services Environment 








Components 


DOS LAN Services builds on the large range of functions previously provided by 
DOS LAN Requester. This section highlights these functions and discusses the 
new features incorporated in DOS LAN Services. 


© Copyright IBM Corp. 1995 


DOS LAN Services Functional Overview 


The 


following functions are provided by DOS LAN Services: 
File redirection 

Print redirection 

Named pipe redirection 

Peer Services (client single-connection resource sharing) 
DOS graphical user interface 

Network DDE/Clipboard for Windows 


Reduced memory requirements 


* Automatic session/optional persistent connection reconnection 


Mailslot support 

LAN API support (including administration) 
Password encryption support 

Message support 


Data buffering/caching 


DOS LAN Services Graphical User Interface 


As previously mentioned, you may access network resources from DOS 
workstations by using any of the three interfaces provided by DOS LAN Services: 
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The 


DOS LAN Services graphical user interface 
Windows interface 


Command line interface (the DOS command prompt) 


graphical user interface provided with DOS LAN Services replaces the DOS 


LAN Requester EZVU-based full-screen interface and now supports DBCS and 
mouse input. This can be used on DOS clients with or without Windows and 


ena 


bles the user to perform the following tasks: 


Log on and log off to/from a LAN Server domain, modify logon assignments 
and re-establish persistent connections, if you have any 


Change logon password and user comment 
List users logged on to the domain 
Modify the appearance of the graphical user interface 


Share directories and printers with other users on the network 


+ View directory-limit information for a shared directory (Windows only) 


The 
any 


Send and receive network messages 


Define private and public applications 


DOS LAN Services graphical user interface may be run in graphics mode on 
monitor/video adapter combination supporting VGA graphics or higher. The 


graphical user interface will gain no benefit from higher resolution graphics. 


lfa 


workstation does not support VGA, the graphical user interface may be run 


in text mode by specifying the /T switch after the NETGUI command. Examples 
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of the graphical user interface in graphics, Windows and text modes are 
illustrated in the following figures: 


User ID: DLSUSRAZ 
Machine ID: DLSREGAZ 
Domain: ANY DOMB1 





Figure 52. Example of DOS LAN Services Graphical User Interface in Graphical Mode 











ser Applications Drives Printers Messages Help 











User ID- DLSUSRO2 
Machine ID: DLSREQO2 
ANYDOHOI 






Domain: 





Figure 53. Example of DOS LAN Services Windows Graphical User Interface 


He 





Figure 54. Example of DOS LAN Services Graphical User Interface in Text Mode 

The DOS LAN Services graphical user interface is packaged with DOS LAN 
Services and is presented as an installation option of DOS LAN Services. Unless 
otherwise specified, it is installed by default. 
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DOS LAN Services and DOS LAN Requester Feature Comparison 
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In this section, we discuss the new features in DOS LAN Services (DLS). 


Interface 

The most visually distinguishing feature between DOS LAN Requester and DOS 
LAN Services is obviously the graphical user interface as discussed in the 
previous section. 


Command line information has also been significantly enhanced. For example, 
when logging on, you are informed of which server serviced your logon, your 
privilege level on the domain, and your network connections. Previously, DOS 
LAN Requesters would only receive the message Command completed 
successfully. 


Peer Service 

The next most important addition to DOS LAN Services is the peer service. This 
service, which is discussed in detail in Chapter 5, “Peer Services” on page 97, 
has been extended to include DOS requesters and allows you to share the 
resources of your DOS workstation with other LAN Server DOS clients, OS/2 LAN 
Requesters, and other Server Message Block (SMB)-based network products. 
Peer services for DOS clients has the same single-session restriction as the 

OS/2 client. 


Reduced Memory Requirements 

Given the limitations imposed by DOS on real mode memory, it is obviously 
critical to minimize the use of it. Continuous efforts are focussed on increasing 
the amount of memory available for applications. The result is that on an 
8086/8088-based workstation configured as a basic redirector running DOS 3.3 
with LAN Support Program, 496KB of conventional memory remains available to 
applications. A similarly configured 386 or 486 workstation running DOS 7.0 with 
the protected mode redirector, which is included with other DOS LAN Services 
enhancements and fixes in APAR IC10086, would leave 621KB of real mode 
memory available. 


Note: The above values are based on 110KB of Upper Memory Block (UMB) 
space. These values represent the amount of conventional memory that is 
available after loading the DOS LAN Services redirector and LAN transport. 


DOS LAN Services Fixes 





To get the DOS LAN Services enhancements and fixes described in this 


chapter contact your IBM customer service representative and ask to be sent 
fixes relating to APAR IC 10086. 


In a Windows environment, DOS LAN Services does not actually use any real 
mode memory when configured as a virtual redirector, since it runs as a 
Windows virtual device driver. 


The following sample files illustrate how you may configure a system to have 
636,368 bytes (621 KB) of memory available to DOS applications after loading 
LAN transport and DOS LAN Services, with FILES=30 and LASTDRIVE=H. 
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Note: 


In this example, LAN Support Program has been used to minimize 


memory utilization. For optimum performance, IBM NetBEUI is recommended 
(the default when you install DLS). 


These sample files were taken from an IBM PS/VP with 8MB of RAM and an IBM 
Auto 16/4 Token Ring ISA Adapter installed. The amount UMB space available 


will vary depending on the 


hardware configuration of the system since hardware 


drivers are loaded into this memory area. 


CONFIG.SYS 


CE=C:\DOS\H 
IGH, UMB 
E=C:\DOS\ 





DEV 
DOS=H 


€ 





M 


























EMM3 86. 


EM.SYS 








EXE NO 





EMS RAM <---See Note 1 








im 


D 

D 

FILES 
BUFF] 
D 
D 
D 








=30 
RS=20 
GH=C: 
GH=C: 
] GH=C: 
LASTDRIVE=H 
STACKS=0, 0 











“ie 


LSP\I 
LSP\I 
LSP\I 








Fil 














id 





Cc 
Cc 
Cc 
D. 

















<--- Ss Note 2 


Ss Note 3 





< 
DXMAOMO! 
DXMC0MO! 
DXMTOMO! 
< 





D.SYS 
D.SYS 
D.SYS 





Note 4 
Note 5 





S 
< 





























DEVICEHIGH=C: \N 





ET \ 





DLSH 


Tr 





iP. SYS <- 6 





S Not 





AUTOEXEC.BAT 


@ECHO OFF 
PROMPT ¢P¢G 
PATH C:\;C:\I1 








NETWORK.INI 


[network] 
computername=DLSR 
lanroot=C: \NET 
autologon=no 
autostart=basic 
guiconfig=0,0,1 
username=USER1 
domain=TESTDOM4 
lslogon=yes 
reconnect=yes 























DOS; C: \NI 





EQO01 





Not 


passwordcaching=yes 


timesync=yes 


[Password Lists] 
USER1=C: \NET\USER1 














. PWL 





a 


Domain List] 
ESTDOM4= 








lB 





Notes: 


1. Memory include and e 


xclude parameters are omitted from the example. 


2. This represents a typical value to support most environments. The 
implications on memory utilization of adjusting this value are negligable. 


3. Buffers are loaded into upper memory, where available, and therefore there 


is no impact on real m 
limited. 


ode memory unless the amount of UMB space is 
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4. Each additional drive letter consumes between 80-100 bytes, and, therefore, 
you should plan your network logon assignments to maximize the available 
memory at the workstation. 


5. Setting the value of stacks to 0,0 conserves memory but may cause 
problems on certain systems. Reset back to the default if your system 
appears unstable. 


6. This driver provides an interface to the redirector. It handles hooking 
interrupts and some initial setup work. Without this driver, DOS LAN 
Services will not function. 


7. The basic redirector program only supports basic network functions such as 
connecting, disconnecting and browsing of shared resources. If additional 
function is required, such as the GUI or peer services capability, then they 
will require the full redirector. Refer to the LAN Server 4.0 Commands and 
Utilities publication for details of the restrictions on the use of the NET USE 
command with the basic redirector. 


Persistent Connections 

Persistent connections are connections that are re-established automatically 
from one logon to the next. They are based on the workstation, not the user ID, 
and so are different from the user logon assignments. Only a local logon is 
required for persistent connections. Be aware that if you need to access 
reconnected resources on a domain server or on an OS/2 peer server (where 
user-level security is used), then it is easiest if you keep your user ID and 
password the same on your local workstation, the domain, and the OS/2 peer 
server. Otherwise, you must specify the password with the NET USE, or you 
must use the GUEST account. 


Each time a user logs off, the current connection information (to both LAN 
Servers and peer servers) is stored in the DLS workstation NET CONNECT.DAT 
file. When another user or the same user logs back on at that workstation, DLS 
attempts to reconnect to those resources. It is important to realize that 
connecting to a resource and accessing that resource are two different actions; in 
order to actually use the resource, the user ID must have the proper 
permissions. 


You can choose to not have automatic reconnections made for a subsequent 
local logon by specifying reconnect=no in the NETWORK.INI file. 


Local Logon 

You can perform both a local logon and a domain logon. To access peer 
resources, only a local logon is necessary. If your user ID and password are the 
same both locally and on the domain, then a local logon also allows you access 
to domain resources; however, you must provide the full UNC name 

(_ server sharename) when making the server connection, because aliases are 
not interpreted with a local logon. In order to use aliases, you must be logged 
on to the domain. 


With only a local logon and no domain logon, you do not receive your domain 
logon assignments. However, DLS will attempt to reconnect any persistent 
connections for that workstation. If your user ID has permission to use these 
reconnected resources, then you will be granted access. If you do not have 
permission, then the connection may be made (for example, drive LPT1 may 
connect to LASERQ), but you could then not actually use the resource. 
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For each user that logs on at a workstation, DLS maintains an unreadable 
password file with the extension PWL. This file contains a local password, 
domain password (if the user has logged on to a domain), and peer services 
passwords (if the user has used peer resources requiring passwords). 


Performance Enhancements 

DOS LAN Services provides a significant increase in performance in comparison 
with DOS LAN Requester, especially in instances where the emphasis is on 
random read access. This is due to the ability of DOS LAN Services requesters 
to use big buffers as cache and through a read ahead function. This subject is 
covered in more detail in “DOS LAN Services Performance Tuning” on page 78. 


CID Enablement 

DOS LAN Services clients are ClD-enabled to allow for attended, lightly attended 
and unattended installation from a code server. This subject is covered in detail 
in Chapter 16, “OS/2 LAN Server 4.0 CID Enablement” on page 359. 


Network Dynamic Data Exchange and Clipboard 

The Network Dynamic Data Exchange (DDE) and Clipboard feature available 
under DOS LAN Services in a Windows environment, extends DDE capabilities 
and the clipboard across the network. This feature does not create a network 
clipboard; it allows other users to access your local clipboard and enables you 
to access other users' clipboards. This feature is discussed in “Network Dynamic 
Data Exchange and Clipboard” on page 32. 


Common Configuration File Structure 

The DOSLAN.INI file, which contains requester configuration parameters for DOS 
LAN Requester, has been replaced in DOS LAN Services with a NETWORK.INI 
file. It is structured in a similar way to the OS/2 LAN Server and OS/2 
Requester's IBMLAN.INI, but requires less in terms of manual configuration for 
tuning purposes because it automatically sets parameters based on the amount 
of XMS memory available in the workstation. 


See “NETWORK.INI Configuration File Parameters” on page 84 for descriptions 
of the NETWORK.INI parameters. A typical NETWORK.INI file is shown in 
Figure 58 on page 87. 





DOS LAN Services and DOS LAN Requester Interoperability 


It is recommended that DOS LAN Services is implemented on DOS workstations 
to allow users to take advantage of the valuable new features outlined in the 
previous section. However, DOS LAN Requesters, previously shipped with OS/2 
LAN Server 1.3, 2.0, or 3.0, or as LAN Enabler 2.0, are supported by OS/2 LAN 
Server 4.0. Chapter 8, “Migration and Coexistence Among LAN Server Versions” 
on page 151, provides an overview of the level of function available to 
requesters when connecting to LAN Servers with different versions of the LAN 
Requester code. Two of the restrictions are detailed in this section. 


LANMSG Public DOS Application Availability 


The LANMSG public DOS application is not automatically available to DOS LAN 
Requesters accessing an OS/2 LAN Server 4.0. You must use the following 
procedure if you have DOS LAN Requester users accessing your OS/2 LAN 
Server 4.0 server who wish to continue to use the LANMSG application: 
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1. Create a batch file called LANMSG.BAT with the following contents: 
DMPC %XSLCNF% CMM_MAIN. EXE 




















2. Copy the batch file onto a server 


3. Create an alias that points to the server and directory where LANMSG.BAT 
was copied to 


4. Create a public DOS application called LANMSG, specifying the 
corresponding alias 


5. Assign the LANMSG application to users that wish to continue to use it 
Note: It is assumed that DMPC.EXE and CMM_MAIN.EXE reside on the 
requester. 


Using the NET ALIAS Command 


From a DOS LAN Services requester, the following command does not succeed 
when the DOS LAN Services requester is logged on to an OS/2 LAN Server 4.0 
domain and is attempting to browse a LAN Server 3.0 domain: 





NET ALTAS /D:domain 














where domain is the domain name. 


When the DOS LAN Services requester is logged on to a LAN Server 3.0 domain, 
the following commands both work when browsing the logon domain, but do not 
work when attempting to browse another LAN Server 3.0 or OS/2 LAN Server 4.0 
domain: 





NET ALTAS /D:domain 
NET ALTAS 























While the DOS LAN Services requester is logged on to a LAN Server 3.0 domain, 
the following commands work: 





NET ALTAS /D:domain 
NET ALIAS aliasname 
NET ALTAS 





























where domain in the above example is the logon domain. 
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The procedure to upgrade a workstation running DOS LAN Requester to DOS 

LAN Services is the same as the procedure to install DOS LAN Services. 

Installing DOS LAN Services on a DOS LAN Requester modifies CONFIG.SYS and 
AUTOEXEC.BAT and replaces DOS LAN Requester references with required DOS 
LAN Services statements. The \DOSLAN directory and contents remains intact. 
Backup copies of the DOS LAN Requester CONFIG.SYS and AUTOEXEC.BAT files 
are created; therefore, you may easily revert to DOS LAN Requester, if 

necessary. 


Once the user is familiar with the new DOS LAN Services interface, it is 
recommended that the \DOSLAN directory be manually deleted to conserve disk 
space. 
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Installation 


Step-by-step installation instructions are provided in LAN Server 4.0: Up and 
Running, chapter 3. As previously discussed, DOS LAN Services provides a 
number of new features. To take full advantage of these components, you should 
take the time to carefully plan your installation. For example, decide whether 
you could make better use of resources that are currently connected to 
workstations by implementing the DOS peer service. Or, enable users to 
discover the benefits of workgroup computing by allowing them to access data 
residing on each other's workstations via the Network DDE and Clipboard 
feature. 


DOS Installation Considerations 


For the optimum memory utilization, DOS LAN Services should be installed on a 
system with UMB and XMS memory available. While DOS LAN Services doesn't 
use EMS memory, it may use UMB and XMS memory to limit the amount of real 
memory that it takes. 

















If you are using an 80386-based system or higher, ensure that the EMM386.EXE 
driver is installed in CONFIG.SYS, and add the NOEMS parameter to maximize the 
amount of UMBs available. On this basis you should include the following 
statements in CONFIG.SYS if you have an 80386-based system: 

DEVICE=C: \DOS\HIMEM. SYS 


DOS=HIGH, UMB 
DEVICE=C: \DOS\EMM3 86.EXE NOEMS RAM 







































































When DOS LAN Services starts, it attempts to load its components into UMB; if 
there is not sufficient UMB memory available, it then tries to load the remainder 
into XMS memory before using real or conventional memory. 


When installing DOS LAN Services with Windows 3.1, it is recommended that you 
configure DOS LAN Services to use the virtual redirector feature. It runs as a 
Windows virtual device driver and therefore does not use any conventional 
memory. 


Once you have calculated the number of drive assignments that a DOS LAN 
Services requester requires, adjust the LASTDRIVE= statement in the requester's 
CONFIG.SYS file to minimize the memory overhead (each unused drive letter 
requires approximately 80 bytes of memory). 

















Notes: 


1. Certain memory managers have exhibited problems when they are used on 
systems with the Monochrome Display Adapter (MDA) and are configured to 
recover upper memory used by this adapter. If you experience a problem 
displaying graphics characters after starting one of the DOS LAN Services 
redirectors, reconfiguring the memory manager not to recover upper 
memory allocated to the MDA may alleviate this problem. 


2. If you are using the PC-DOS 6.3 RAMSETUP program to maximize the 
availability of conventional memory by loading drivers into upper memory, 
ignore the recommendation to delete the line in CONFIG.SYS beginning 
DEVICE=C: \NET\DLSHELP.SYS. This statement is required for the requester to 
start successfully. 
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Network Adapter Installation Considerations 
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DOS LAN Services supports an extensive list of IBM and OEM network adapters 
as standard. This section documents observations relevant to a number of 
specific network adapters and includes step-by-step procedures that need to be 
followed to enable OEM adapters (not on the list of supported adapters) to be 
used with DOS LAN Services. 


Network Adapter Specific Hints and Tips 

Use the following list to determine whether any additional configuration is 
required for your selected network adapter to function correctly with DOS LAN 
Services, or whether there are restrictions in using your adapter with DOS LAN 
Services. 


Token Ring Network Adapter Problem Determination 


A token-ring open lobe cable condition on a DOS LAN Services 
workstation does not produce an error message that would indicate such 
a condition. If you have a workstation with a token-ring adaper installed 
that appears to boot correctly and then exhibits the following symptoms, 
the underlying cause may be related to a cabling problem: 


NET START executes slowly, but is successful with netgui specified 
as an option for the autostart parameter of the NETWORK.INI file. 


Logging on from the command line using the NET LOGON command 
reports: 





NET2182: The requested service has already been started 





* A local logon from the DOS LAN Services Windows graphical user 
interface is successful. 


- A validated logon from the DOS LAN Services Windows graphical 
user interface results in a failure, stating that the user has no 
privileges on the network. 


IEEE 802.2 Support on Ethernet Adapters 


If you have an Ethernet adapter and require IEEE 802.2 support through 
the DXMEOMOD.SYS and DXMTOMOD.SYS device drivers, or if Windows 
or DOS memory managers are being used with the LAN Support 
Program, you need to specify that application programs should be 
prevented from intercepting the X'5C' interrupt issued by the NETBIOS 
device driver. This is achieved by adding cF=y to the DXMTOMOD.SYS 
line in CONFIG.SYS. 


IBM Etherstreamer MC32 and NET START 





If you receive a NET 54: The network is busy error while performing a 
NET START on a system with the IBM Etherstreamer MC32 adapter 
installed, add NET START NETBIND to AUTOEXEC.BAT before the line 
C:\NET\NET START. 


IBM ISA Ethernet (10Base2,T) Adapter 


If you are using the PS/ValuePoint ISA 10Base-T/10Base2 Ethernet 
Adapter, be sure that you run the DOS LAN Services installation program 
with the /I parameter, and then load LAN Support Program using 
DXMAID. 
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Installation of OEM Network Adapters 

If you are installing DOS LAN Services to run on a network adapter that is not on 
the list of supported adapters displayed by the installation program, check 
whether or not an OEMSETUP.INF file resides on the driver diskette that should 
be supplied with the adapter. If so, you can use the file with the DOS LAN 
Services installation program to configure your adapter by using the steps 
detailed in this section. If this file does not exist, you need to configure the 
adapter by following the instructions that came with it, after installing DOS LAN 
Services. 


To be able to use the OEMSETUP.INF file as input to the DOS LAN Services 
installation program, the following steps must be followed prior to running 
INSTALL.EXE. The following examples are taken from the Olicom Token-Ring 
Network 16/4 Adapter driver diskette. 


1. Edit the OEMSETUP.INF file and verify that it contains both a [disks] section 
and an adapter section that contains a devdir parameter. If so, proceed as 
follows. Otherwise, you need to configure this adapter separately, as per the 
OEM supplied instructions, after installing DOS LAN Services. 


2. In the [disks] section, verify that the symbol (usually A or 1) is defined as the 
absolute path (minus any drive letter) to where the adapter driver resides. 
The name of the driver may be determined by reading the OEM supplied 
documentation shipped with the adapter. 


For example, if the driver called olitok16.dos is located in the following 
path of the OEM supplied diskette: 


\MSLANMAN . DOS\DRIVERS \ TOKENRNG \ OLITOK16 


























you need to ensure that the [disks] section contains the following line: 








1=\OLICOM\MSLANMAN .DOS\DRIVERS\TOKENRNG\OLITOK16 ,.... 


























where "...." represents the adapter description text that should not be 
changed. 


3. The adapter section containing the devdir parameter would need to have the 
following contents: 


[olil64a] 
devdir=1:olitok16.dos 
device=olitok16.dos, @devdir\olitok16.dos 


where 1 is the symbol defined in the [disks] section. 


4. Run the DOS LAN Services installation program. When presented with the 
list of adapters, choose Network card not shown on the list below to be 
prompted for the location of the OEMSETUP.INF file. Enter the fully qualified 
path (including the drive letter) to where the file is located. 


For example, if this file is in the root directory of the OEM-supplied disk, 
insert the disk in drive A:, type A: \, and press Enter. 


The DOS LAN Services installation should then proceed normally. 
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Installation of DOS LAN Services 
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The installation of DOS LAN Services is further simplified with detailed 
context-sensitive help and the inclusion of the LAN transport component 
installation. 
To install DOS LAN Services, the following software is required: 

DOS 3.3, DOS 5.02 or higher 

OS/2 LAN Server 4.0 Entry or Advanced 

Microsoft Windows 3.1 (optional) 


Note: Microsoft Windows 3.0 is not supported by DOS LAN Services 
because the DOS LAN Services code base is dependent upon certain 
Windows 3.1 APIs. 


With the DOS LAN Services - Disk 1 (of 3) in the diskette drive type: 


a:install 
where a is the diskette drive letter. 


Default installation options are shown in the next two tables. 


Table 1. DOS LAN Services Installation Options Screen 1 


Installation Option Default Setting 
Graphical User Interface Install GUI 

Peer Services Install Peer Services 
Windows Support Install Windows Support 
Protocol Driver IBM NetBEUI 


Table 2. DOS LAN Services Installation Options Screen 2 


























Installation Option Default Setting 

Machine ID Must be entered by user 

User name Must be entered by user 

Domain name Must be entered by user 

Redirector Use the full redirector 

Startup option Run DOS LAN Services and log on 

Path C:\NET 

Network card Automatically detected by DOS LAN Services 














For a detailed explanation of each option, refer to Network Administrator 
Reference Volume 1: Planning, Installation and Configuration which is shipped 
with OS/2 LAN Server 4.0 as an installable online book. 


Note: If you reinstall Windows or modify the DOS LAN Services configuration file 
NETWORK.INI you must run the DOS LAN Services install program 
(INSTALL.EXE). Also note that DOS LAN Services cannot be run from the DOS 
shell. Therefore, you should either comment-out or remove the DOSSHELL 
statement from your AUTOEXEC.BAT or move it to run after the DOS LAN 
Services statements. 
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While referring to this section for additional guidance, follow the installation 
instructions displayed on the screen and select the options that best suit your 
requirements. 


Configuring your Network Adapter 

Another feature incorporated in DOS LAN Services that further simplifies the 
installation process is automatic network card detection. If the adapter is not 
supported by LAN Support Program and the option Change driver for protocol is 
selected, the default protocol driver, IBM NetBEUI, will continue to be loaded. If, 
however, the adapter is supported by LAN Support Program, and the option 
Change driver for protocol is selected, you may then choose to optimize the 
protocol driver for either memory usage or speed. LAN Support Program, 
selected by choosing Install 802.2 support, provides the optimum memory 
availability whereas IBM NetBEUI ensures the optimum performance. 


Selecting the Redirector 
It is important to understand the differences between the types of redirectors 
available. A brief description of each follows: 


Basic Redirector 


The basic redirector provides all standard requester functions, such as 
connecting, disconnecting and browsing. It requires less memory and 
disk space and should therefore be used if you: 


- Have limited memory available on your workstation 
- Do not wish to use aliases to identify resources 
- Do not plan to use Windows 


- Have a workstation with limited processing power, such as an 8086 
or 8088 


Full Redirector 


The full redirector provides advanced network functions, such as named 
pipes, as well as increased performance and full API support. 


* Virtual Redirector 


The virtual redirector provides the optimum memory availability since it 
does not use conventional memory, because it runs as a Windows virtual 
device driver. 


DOS LAN Services Installation Troubleshooting 

Should you experience any problems setting up DOS LAN Services, refer to the 
CONNECT.DAT file that is installed in the same directory as you specified to 
store the DOS LAN Services files (the default is C: \NET). 





DOS LAN Services Configuration Tailoring 

The NETWORK.INI file resides in the directory where you specified DOS LAN 
Services to be installed. Refer to “NETWORK.INI Configuration File Parameters” 
on page 84 for detailed descriptions of the NETWORK.INI parameters. 
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DOS LAN Services Performance Tuning 

The default installation parameter values have been selected to provide the 
optimum performance/memory utilization ratio. The DOS LAN Services autocache 
parameter, when set to yes automatically allocates the values of numbigbuf, 
sizbigbuf and extraheap based on the amount of XMS memory available. 
However, if a performance problem is identified then you may set autocache to no 
and manually adjust the values of the following parameters: 


Work Buffers are used to construct SMBs prior to their delivery to the server. 
The sizworkbuf parameter specifies the size of work buffers; however, this 
value rarely needs to be changed because small data read requests are 
processed via the cache provided with big buffers. 


Big Buffers are used, as with previous versions of requesters, to process 
large file transfers. However, with DOS LAN Services, they are now also 
used for file caching which provides an obvious performance advantage. 


DOS LAN Services Command Restrictions 
The following DOS commands may not be used with redirected drives: 


BACKUP 

* CHKDSK (Check Disk) 

* DISKCOMP (Disk Compare) - Use the COMP (Compare) command to 
compare files 
DISKCOPY (Disk Copy) - Use the COPY and XCOPY commands to copy files 
FDISK 

+ FORMAT 

+ JOIN 

+ LABEL - You may not change the label of a network drive that you are using 
PRINT - Use the NET PRINT (or NET COPY) command if you are using 
network devices 

+ RECOVER 

+ RESTORE 
SUBST (Substitute) 

* SYS 

- VERIFY 


The following are the only commands that you can use with UNC names: 


> TYPE 
PRINT 


Installing and Running DOS LAN Services on Windows 
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Installing DOS LAN Services on a workstation running Windows with the Install 
Windows Support option selected provides you with seamless access to all of the 
features of DOS LAN Services from the Windows graphical user interface. In this 
section, we discuss what modifications are made to the workstation configuration 
and look at what additional function is brought to the Windows user's Desktop. 
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Installing DOS LAN Services in a Windows Environment 
In Windows, DOS LAN Services requires the following dynamic link library files 
(DLLs) to perform network tasks such as displaying active servers, browsing 
available network resources, and managing printer queues: 


NETAPI.DLL 
* PMSPL.DLL 


The following files provide the connection which integrates DOS LAN Services 
and Windows: 


* WINDLS.DLL 
DLSNET.EXE 

* RUNLSAPP.EXE 
DLSNET.DRV 


The files in these lists, plus DLSNET.HLP and WINPOPUP.EXE, are provided on 
the DOS LAN Services diskettes and are installed with DOS LAN Services. 


Following the installation of DOS LAN Services, with Windows support selected, 
when you next run Windows, you are prompted whether or not you wish the 
necessary modifications to be automatically applied to the Windows 
configuration. If you select Yes, the following changes are applied: 


[boot] 
network.drv=dlsnet.drv 


[boot.description] 
network.drv=IBM DOS LAN Services 














[network] 
computername=Machine ID 
lanroot=C: \NET 
domain=Domain name 




















If you are running in 386-enhanced mode, the following is also added: 


[386Enh] 
network=vnetbios.386, vnetsup.386, vredir.386 





The following modifications are also applied to WIN.INI: 


[windows] 
load=wdls 


[network] 
Restore=0 


You should also check to ensure that the latest versions of HIMEM.SYS, 
EMM386.EXE and SMARTDRV.SYS are being used. You may do this by 
comparing their dates in the \DOS and \WINDOWS subdirectories. 


Running DOS LAN Services on Windows 
Following installation, DOS LAN Services may be configured via the Network 
program icon located in the Windows Control Panel. The DOS LAN Services 
Configuration window, as shown in Figure 55 on page 80, enables you to modify 
options for logging on at startup, resource sharing, and network warnings. 
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Figure 55. DOS LAN Services Windows Configuration Window 


The DOS LAN Services group contains program icons to enable you to logon, 
logoff, start the Network DDE and Clipboard feature, and access the DOS LAN 
Services main window as shown in Figure 53 on page 67. As you can see, all of 
the functions accessible from the DOS LAN Services DOS graphical user 
interface are available and integrated into the windows environment. For 
example, if you select the Printers pull-down menu, you are provided with direct 
access to the Windows Print Manager. 


DOS LAN Services Windows Shared Applications 


To further illustrate DOS LAN Services integration, selecting the Applications 
pull-down menu and the Shared Applications item presents you with the window 
shown in Figure 56. 


IBM DOS LAN Services 
4 User Applications Drives Printers Messages Help 








User ID: DLSREQO?2 
Machine ID- DLSREQO2 
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Program Groups 
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Haak for Windows 
IBM DOS LAN Services 
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Public DOS Applications 
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Figure 56. DOS LAN Services LAN Server Application Installation Window 
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You are presented with a list of shared applications that the user has access to. 
You may select an option from this list to be added to an existing program group 
or you may actually create a new group for this application from the window. 


Once you have added this shared application, and you subsequently attempt to 
run the application, you are prompted to log on to the domain where the 
application resides (if you are not already logged on). This is illustrated in 
Figure 57. 





Windows 
Selup Diagnostics 


To run this application, you must be logged on 
to domain ANYDOMO1. Do you want to log on 
now? BLSoO70 














Figure 57. DOS LAN Services Shared Application Access Prompt 


Configuring DOS LAN Services Windows Applications 

Certain applications manipulate resources and store data in ways that require 
changes to be applied to the network environment to provide seamless 
integration. Generally, these applications require one or both of the following: 


More environment space than the default provides 
* Their own working directories 


To assist you in integrating applications into your DOS LAN Services Windows 
environment, DOS LAN Services provides the following environment variables. 


WLRENV 


The WLRENV environment variable allows you to adjust the DOS Windows 
environment space by changing its value (default = 2048 bytes). Applications 
can require more or less than this amount. The format of the environment 
variable is: 





SET WLRENV=nnnn 











where nnnn equals any value allowed by DOS. 
WLRWORKDIR 


The WLRWORKDIR environment variable allows you to establish a working 
directory for a shared application that requires one. Implementing this local 
environment variable at the workstation overrides any working directories 
defined by the administrator. 
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If the WLRWORKDIR environment variable is set to a non-empty string, the value 

of this environment variable sets the working directory. For example, if you enter 

the DOS command SET WLRWORKDIR=C: \DATA, the system sets the current directory 
to C:\DATA. 

















The format of the WLRWORKDIR variable is: 
SET WLRWORKDIR=d: \symbol 














where d is defined as the logical drive or specified with the %w symbol. The 
following predefined symbols increase the flexibility of this variable. If any of 
these predefined symbols appear in the WLRWORKDIR string, they are replaced 
with other characters before the working directory is set. If no drive letter or 
drive letter variable is specified, the default is the current drive. 


The following table provides details of the predefined symbols that may be 
selected. 


Table 3. Predefined WLRWORKDIR Environment Variable Symbols Values 
Symbol Substitution 























Yo Drive letter for the application working directory (as defined at the server 
and connected at program startup) 

%p Drive letter for the application program directory (as defined at the server 
and connected at program startup) 

%a Application's program alias 

You Logged-on user's user ID 

%od Logged-on user's LAN Server domain 

So%o % 














The following example sets the working directory at program startup to 
C:\useria\program-alias: 





* WLRWORKDIR=C: \%u\%a 








This example would support a convention where users have a name 
directory at their workstation with a program-specific subdirectory below 
it. 


The following example sets the working directory at program startup to the 
program working directory (as defined at the server) plus a user-specific 
subdirectory with the same name as the logged-on user's user ID: 





* WLRWORKDIR=%w: \%u 








Notes: 


1. Predefined symbols are case-sensitive. You must type them in lowercase for 
substitution to occur. 


2. Predefined symbols and characters to be interpreted can be combined in 
whatever order is required, providing that it constitutes a valid path. If a 
drive letter is not provided as part of the expanded WLRWORKDIR value, the 
string is interpreted as a subdirectory below the current directory (as though 
a change directory (CD) command were issued from DOS). 


3. After substitution of special symbols, the specified working directory must 
exist on the specified drive or below the current directory if no drive is 
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specified. Directories are not automatically created when the application 
starts. 


This method of setting the working directory is not supported by the 
non-Windows version of DOS LAN Services. 





Installing and Running DOS LAN Services on OS/2 


Neither DOS LAN Services or PC LAN Program are supported in the OS/2 
emulated DOS environment. DOS LAN Services and PC LAN Program requesters 
may, however, run in an OS/2 DOS session which has been started with a 
specific version of DOS. Specific and emulated DOS sessions are explained in 
detail in the OS/2 documentation. 


Network assignments made in a specific DOS session with DOS LAN Services or 
PC LAN Program are only available within that session. You may, however, have 
up to four DOS LAN Services requesters running on one OS/2 workstation. For 
information on setting up single or multiple DOS LAN Services sessions on OS/2 
workstations please refer to the LAN Server 4.0 online reference Volume 1: 
Planning, Installation and Configuration. This subject also is discussed in 
“Installing DOS LAN Services VDD” on page 414. 


Notes: 


1. Please ensure that you have purchased a license for the version of DOS that 
you are running, and do not start DOS LAN Services from a specific DOS 
session on which the VNETAPI.SYS device driver has been installed. 


2. For each specific Virtual DOS Machine (VDM) you must set the 
DPMI_DOS_API DOS setting to ENABLED otherwise you may experience an 
OS/2 program exception when using a mouse with the DOS LAN Services 
graphical user interface. 


3. If you plan to run multiple PC LAN Program requesters from one workstation, 
you must specify a different machine ID for each DOS session. To specify 
different machine IDs: 


a. At the OS/2 prompt, type: 















































COPY C:\NET\NETWORK.INI C:\machineID\NETWORK.IN 











where machinelID is a unique directory on drive C: for each DOS session. 


b. After you have made copies of the C:\NET\NETWORK.INI file for each 
DOS session, delete the NETWORK.INI file in the C:\NET subdirectory. 














c. Add C:\machineID and C: \NET to the path statement of each 
AUTOEXEC.BAT file. For example, if you are running three sessions, edit 
all three AUTOEXEC.BAT files. Add a machine ID for each DOS LAN 
Services session. 


d. Edit each NETWORK.INI file associated with a machine ID to: 


Specify a unique machine ID and user name to match the names to 
be used for each session. 














+ Change the LANROOT=C: \NET statement to LANROOT=C: \machinelID for 
each DOS LAN Services session you are creating. 


e. Copy the NET.EXE, *.MSG, *.DAT, MESSENGR.EXE, DLRPEER.EXE, 
NETPOPUP.EXE, DZG4.EXE and PQ.SPL files from the NET subdirectory 
into each C: \machineID subdirectory you create. 
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f. Assign the remaining files in the NET subdirectory read-only permission 
as a precaution against multiple sessions accessing executables in the 
NET directory. To set the permissions, type the following command: 

ATTRIB C:\NET\*.* +R 

















NETWORK.INI Configuration File Parameters 


The NETWORK.INI file resides in the directory where you installed DOS LAN 
Services. NETWORK.INI has the following main sections: 


* Network 

* Messenger 
* Netpopup 
* Peer 


Note: There are also other sections that may appear in the NETWORK.INI as 
you configure your environment, such as Password Lists, Local Applications, and 
Network Applications. 


You can change the NETWORK. INI file manually or by using the DOS LAN 
Services Setup program. The following tables provide information on parameters 
in the Network, Messenger and Netpopup sections. The Peer section 
parameters are discussed at the end of Chapter 5, “Peer Services.” 


NETWORK.INI Network Parameters 


The following table provides details of the parameters in the [network] section of 
NETWORK.INI. 


Table 4 (Page 1 of 3). NETWORK.INI Network Section Parameter Values 


Parameter Description Valid Values Default 
Value 


computername Identifies the workstation to the Up to 15 alphanumeric Name 
network characters or special specified 
characters including ! # at 
$%&()E_{}U>~ installation 
lanroot Directory where DOS LAN Fully qualified path CANET 
Services is installed and starts (drive letter and path) 


autologon Prompts user to logon to a Yes 
domain when DOS LAN 
Services starts 


autostart Indicates which services to netbeui, basic, full, Basic 


start when NET START is entered messenger, netpopup, 
peer 





username Identifies the user to the Up to 20 alphanumeric Name 
network characters or special specified 
characters including ! # at 
$%&()E_{}U>~ installation 


domain Name of the domain that the Up to 15 alphanumeric Name 
workstation belongs to characters or special specified 
characters including ! # at 
$%&()¢_{}U>~ installation 


reconnect Specifies whether persistent Yes 
connections are reconnected 
when logging on 
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Table 4 (Page 2 of 3). NETWORK.INI Network Section Parameter Values 


Parameter Description Valid Values Default 
Value 


lslogon Specifies whether logon 
verification is to be performed 
by the domain controller 


Yes, No No 


numbigbuf , Specifies the number of big 0 to 4096 2 
buffers to use (Full and Virtual 


redirectors only) 


sizebigbuf , Specifies the size of big buffers 4096 to 32768 4096 
in KB (Full and Virtual 


redirectors only) 


numworkbuf Specifies the number of work 2 to 16 2 
buffers to use 


sizworkbuf Specifies the size of work 512 to 16384 1024 
buffers to use in KB 





extraheap , Allocates extra heap space for 1024 to 32768 0 
the redirector, and should be 
tuned for file-intensive 


applications, such as databases 


autocache Automatically allocates 
numbigbuf, sizbigbuf, and 
extraheap based on the amount 
of XMS memory available, 
overriding the individual values 
set for these parameters, and 
is recommended to increase 
performance 


Yes, No Yes 


printbuftime Specifies the amount of time, in 0 to 65535 0 
seconds, before a print job is 
sent to the server after the 


print job is submitted 





lanas Specifies the number of LAN 0to7 1 
adapter cards used by the 


workstation 


ripl Identifies a remote IPL Yes, No No 
workstation 


passwordcaching} Indicates that passwords are to Yes, No Yes 
be cached to a file and saves 
passwords to servers in a 
password protected file so the 
user does not have to enter a 
password for each server that 
they access 








browsealias , Defines whether netnames or 
aliases are displayed when 


Yes, No Yes 


using the Browse option ina 
Windows environment 
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Table 4 (Page 3 of 3). NETWORK.INI Network Section Parameter Values 
Default 


Parameter Description Valid Values 
Value 


timesync Specifies whether or not the Yes, No Yes 


time on the local machine 
should be synchronized with 
the time at the domain 
controller at logon 





Notes: 


1. This parameter must be manually added to the NETWORK.INI file to change the default. The 
installation program does not add this parameter to the NETWORK.INI file. 


2. This parameter is overridden by autocache=yes. 


3. Browsing for aliases is valid only on LAN Server domains. If this parameter is set to Yes, 
aliases are browsed. If no aliases exist on the domain, netnames are browsed automatically. 
If this parameter is set to No, browsing for aliases is not attempted. 


4. While logon assignments are reestablished whenever you log on to the domain on which 
they exist, additional connections that you made to shared directories or printers, known as 
persistent connections, are also reestablished providing that you log on at the same 
workstation. 


5. If this parameter is not specified, DOS LAN Services synchronizes the time on the local 
machine with the time at the domain controller at logon. The length of time that it takes to 
log on will be reduced if timesync=no is added to the [network] section of NETWORK.INI; 
however, the time at the local machine will not be synchronized with the domain controller. 











NETWORK.INI Messenger Parameters 


The following table provides information on the parameters in the [messenger] 
section of NETWORK.INI. 


Table 5. NETWORK.INI Messenger Section Parameter Values 








Parameter Description Valid Values Default Value 
logfile The name of the file Alphanumeric MESSAGES.LOG 
where received characters. See the 
messages are logged DOS user's guide for 


valid characters that 
may be used when 
creating a file 








sizemembuf Specifies the size of the 512 to 4096 512 
message buffer to use 
in KB 

nummsgnames Specifies the number of 2to8 2 


message names to be 
added to the 
workstation 

















NETWORK.INI Netpopup Parameter 


The following table provides information on the [netpopup] section of 
NETWORK.INI. 
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Table 6. NETWORK.INI Netpopup Section Parameter Values 
Default 


Parameter Description Valid Values 
Value 


msgtimeout Defines the length of time, in -1 to 1800 60 
seconds, that a message is 


displayed if Esc is not pressed. 
If the value is set to -1,a 
message is displayed until Esc 
is pressed. 














Example NETWORK.INI File 
The following is a sample NETWORK. INI file. 





[network] 
computername=DLSREQO02 
lanroot=C:\NET 
autostart=netbeui, full,peer 
dospophotkey=N 
guiconfig=0,0,1 
username=DLSUSR02 
domain=DOMAIN_A 
1lslogon=no 
reconnect=yes 
passwordcaching=yes 
printbuftime=15 








messenger ] 
logfile=MESSAGES .LOG 
sizemessbuf=1024 











netpopup] 
msgtimeout=30 





peer] 
openmode=3 
xmitsize=4096 


Password Lists] 
DLSUSRO2=C: \NET\DLSUSRO2. PWL 





Local Applications] 
LOTUS=LOTUS 123 ver 3.3 








Network Applications] 
DIAG=System Diagnostics 











Figure 58. Sample DOS LAN Services NETWORK.INI File 


DOS LAN Services and TCP/IP Coexistence 


The DOS LAN Services requester and IBM TCP/IP 2.1.1 for DOS Stack Kit, which 
is now included as a component of the OS/2 LAN Server 4.0 package, can 
coexist in one machine sharing the same network adapter. The LAN Support 
Program (LSP) provides a full implementation of the Network Driver Interface 
Specification (NDIS). This enables you to run the regular NetBIOS protocol stack 
and the NDIS-conforming TCP/IP protocol stack, supplied with the TCP/IP 2.1.1 
for DOS Stack Kit, on the same network adapter. The DOS LAN Services 
requester can then access servers through the TCP/IP network. This capability, 
combined with the ability of OS/2 servers and requesters to run the dual protocol 
stack, gives more flexibility to LAN system design. 
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Notes: 


1. You may run into memory problems when running both the TCP/IP and 
NetBIOS protocol stacks on a DOS LAN Services workstation. 


2. The performance of NetBIOS over TCP/IP for DOS LAN Services is not nearly 
as good as TCPBEUI for OS/2 LAN Requesters, due to the Ring 0 
implementation advantage under OS/2. For more on this, see “NetBIOS over 
TCP/IP (TCPBEUI)” on page 44. 


Using LSP with the IBMTOK NDIS driver, it is possible to configure your 
workstation so that you can use TCP/IP and NetBIOS protocols at the same time 
as shown in Figure 59. 
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Figure 59. DOS LAN Services Using NetBIOS and TCP/IP 


Release levels used for this example are: 


IBM PC-DOS 6.3 

LSP 1.36 (shipped with OS/2 LAN Server 4.0) 

Microsoft Windows 3.11 

DOS LAN Services 4.00 (shipped with OS/2 LAN Server 4.0) 
TCP/IP 2.1.1 for DOS Stack Kit (shipped with OS/2 LAN Server 4.0) 


The following are the CONFIG.SYS, AUTOEXEC.BAT, PROTOCOL.INI files and 
NETWORK.INI used in this example: 
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DEVICE=C: \DOS\HIMEM. SYS 

DOS=HIGH, UMB 

DEVICE=C: \DOS\EMM386.EXE NOEMS RAM 
DEVICE=C: \DOS\SETVER. EXE 

DEVICE=C: \WINDOWS\SMARTDRV.EXE /DOUBLE_BUFFER 
FILES=30 

BUFFERS=10 

LASTDRIVE=Z 

STACKS=9 , 256 

DEVICE = C:\NET\PROTMAN.DOS /1I:C:\NET 
DEVICE = C:\NET\IBMTOK.DOS 

DEVICE = C:\NET\DXMAOMOD.SYS 001 
DEVICE = C:\NET\DXMJOMOD.SYS 

DEVICE = C:\NET\ANSI.SYS 

DEVICE = C:\TCPDOS\BIN\DOSTCP.SYS 
DEVICE = C:\NET\DLSHELP.SYS 











Figure 60. CONFIG.SYS File for DOS LAN Services and TCP/IP for DOS 


CONFIG.SYS in this example is using PROTOCOL.INI and the IBMTOK.DOS 
token-ring adapter driver in the C:\NET directory. You can also set up your 
system to use PROTOCOL.INI from the C:\TCPDOS\ETC directory and 
IBMTOK.DOS from the C:\TCPDOS\BIN directory. 








C:\NET\NETBIND 

SET ETC=C:\TCPDOS\ETC 
@ECHO OFF 
PROMPT $p$g 
P. 

Ss 

Cc 























ATH=C: \NET;C:\DOS;C:\TCPDOS\BIN; C: \WINDOWS 
ET TEMP=C:\DOS 

: \DOS\MOUSE. COM 

SHARE 
CALL TCPSTART 
C:\NET\NET START 
WIN 









































Figure 61. AUTOEXEC.BAT File for DOS LAN Services and TCP/IP for DOS 


The TCP/IP customization program, CUSTOM, warns you if the NETBIND 
command is not on the first line of AUTOEXEC.BAT. 
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[PROTMAN_MOD] 
DriverName = PROTMANS 
[DXMAIDXCFG] 
DXMJOMOD_MOD = DXMJOMOD.NIF 
[TCPIP_V21] 
DriverName = DOSNDISS 
Bindings = IBMTOK_NIF 
[DXMJOMOD_MOD] 
DriverName = NETBEUIS 
Bindings = IBMTOK_NIF 
NCBS = 15 
ADAPTRATE = 1000 
WINDOWERRORS = 0 
PIGGYBACKACKS = 1 
DATAGRAMPACKETS = 
PACKETS = 50 
PIPELINE = 20 
MAXTRANSMITS 
MINTRANSMITS 
LANABASE = 0 
[IBMTOK_NIF 
DriverName = IBMTOKS 
EARLYRELEASE 
MAXTRANSMITS = 6 
RECVBUFS = 2 
RECVBUFSIZI 
XMITBUFS = 
XMITBUFSIZI 
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Figure 62. \NET\PROTOCOL.INI File for DOS LAN Services and TCP/IP for DOS 


In this PROTOCOL.INI, we have only defined a NetBIOS interface using 
DXMJOMOD and the TCP/IP interface. 


Note: If you are using the C:\NET\PROTOCOL.INI file for your configuration, the 
TCP/IP for DOS customizing program does not correctly update the Bindings 
parameter. You must manually update this parameter. 








[network] 
computername=DLSREQO02 
lanroot=C: \NET 
autostart=full 
guiconfig=0,0,1 
username=DLSUSR02 
domain=ANYDOM01 
lslogon=yes 
reconnect=no 
passwordcaching=yes 








[Password Lists] 
DLSUSRO2=C: \NET\DLSUSRO2. PWL 





[Domain List] 
ANYDOM01= 











Figure 63. NETWORK.INI File for DOS LAN Services and TCP/IP for DOS Coexistence 


TCP/IP for DOS provides a group for Windows. To define the TCP/IP group in 
your Windows Desktop, select File and New. Add the program group by typing 
C:\TCPDOS\BIN\TCPDOS.GRP in the input field. The group contains icons for 
applications that run in the Windows environment. 




















The following lines are automatically added to the Windows SYSTEM.INI: 
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[386Enh] 
UniqueDOSPSP=True 
InDOSPolling=True 

















NetBIOS for TCP/IP for DOS (RFC 1001/1002) 


NetBIOS for TCP/IP for DOS (NBTCP) is an implementation of the RFCs 1001 and 
1002. These RFCs specify a couple of different approaches that can be used to 
implement NetBIOS over TCP/IP. They are B-Node (Broadcast Node), P-Node 
(Point-to-Point Node) and M-Node (Mixed Node, a combination of P-Node and 
B-Node), and are defined as follows: 


+ B-Node implementations require that during NetBIOS name registration, 
network broadcasts be made for name finds and defense. 
P-Node implementations alleviate the network broadcast requirements by 
requiring all NetBIOS name transactions be handled through a NetBIOS 
nameserver. 

+ M-Node implementations are a combination of the aforementioned 
implementations. 


NBTCP is a B-Node implementation with P-Node extensions. This 
implementation is very similar to the IBM OS/2 implementation. NBTCP 
supports NetBIOS name broadcasts, plus it can query a domain nameserver to 
provide the same features as a NetBIOS nameserver. 


An application using NBTCP cannot communicate with another application using 
the native NetBIOS. Even if the applications are written to the NetBIOS 
programming interface, TCP/IP protocol stacks cannot talk with NetBIOS protocol 
stacks. The communicating machines must use the same protocol stacks. 


This configuration supports WAN access over IP routers as shown in Figure 64 
on page 92. 
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Figure 64. DOS LAN Services Access to Server Using TCP/IP NetBIOS 


Release levels for this example are: 
IBM PC-DOS 6.3 
Windows 3.11 


DOS LAN Services 4.00 (shipped with OS/2 LAN Server 4.0) 
TCP/IP 2.1.1 for DOS Stack Kit (shipped with OS/2 LAN Server 4.0) 


The following is the recommended order in which you should install the above 





















































components: 

1. Install Windows 3.11 (if required and not already installed) 

2. Install DOS LAN Services 

3. Install TCP/IP 2.1.1 for DOS Stack Kit 

4. Run C:\TCPDOS\BIN\CUSTOM. EXE from the command prompt 
5. Manually add C: \TCPDOS\BIN\NBTCP. EXE to AUTOEXEC.BAT 
6. Restart the workstation 

7. Run TCPCHECK 











As stated in step 5, you must manually add the line C: \TCPDOS\BIN\NBTCP. EXE to 
your AUTOEXEC.BAT file. This line must appear after CALL TCPSTART and before 
C:\NET\NET START as illustrated in Figure 66 on page 93. 





















































Alternatively you may edit C: \TCPDOS\BIN\TCPSTART. BAT and include the line 
NBTCP.EXE between the lines REM Begin_User_Customisation and REM 
End_User_Customisation to automatically load NetBIOS for TCP/IP. 




















The following are the CONFIG.SYS, AUTOEXEC.BAT, PROTOCOL.INI files and 
NETWORK.INI used in this example: 
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EVICE=C: \DOS\HIMEM. SYS 
OS=HIGH, UMB 
EVICE=C: \DOS\EMM386.EXE NOEMS RAM 
EVICE=C: \DOS\SETVER. EXE 
EVICE=C : \WINDOWS\SMARTDRV.EXE /DOUBLE_BUFFER 
ILES=30 






















































































EVICE = C:\TCPDOS\BIN\PROTMAN.DOS /I:C:\TCPDOS\ETC 
EVICE = C:\TCPDOS\BIN\IBMTOK. DOS 

\DOS\ANSI.SYS 
: \TCPDOS\BIN\DOSTCP. SYS 
\NET\DLSHELP. SYS 
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Figure 65. CONFIG.SYS file for DOS LAN Services and NetBIOS for TCP/IP 


CONFIG.SYS in this example is using PROTOCOL.INI and IBMTOK.DOS token 
ring driver provided by TCP/IP for DOS. These environments do not require the 
LAN Support Program to be installed. 





C: \TCPDOS\BIN\NETBIND 
SET ETC=C: \TCPDOS\ETC 
@ECHO OFF 
P 
P. 














ROMPT Sp$g 
ATH=C: \NET;C:\DOS;C:\WINDOWS;C:\TCPDOS\BIN 
ET TEMP=C:\DOS 

C:\DOS\MOUSE.COM 

CALL TCPSTART 
C:\TCPDOS\BIN\NBTCP. EXE 
C:\NET\NET START 

WIN 














n 












































Figure 66. AUTOEXEC.BAT file for DOS LAN Services and NetBIOS for TCP/IP 


[PROTMAN_MOD] 
DriverName = PROTMANS 
[TCPIP_V21] 

DriverName = DOSNDIS$ 
Bindings = IBMTOK,,, 

[IBMTOK] 

DriverName = IBMTOKS 

EARLYRELEASE 
MAXTRANSMITS = 6 
RECVBUFS = 2 


























RECVBUFSIZE = 256 
XMITBUFS = 1 
XMITBUFSIZE = 2040 














Figure 67. \TCPDOS\ETC\PROTOCOL.INI file for DOS LAN Services and NetBIOS for 
TCP/IP 


In this PROTOCOL.INI we have only defined a TCP/IP interface because NetBIOS 
for TCP/IP uses the TCP/IP interface. 
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[network] 
computername=DLSREQO02 
lanroot=C:\NET 
autostart=full 
guiconfig=0,0,1 
username=DLSUSRO02 
domain=ANYDOM01 
lslogon=yes 
reconnect=no 
passwordcaching=yes 








[Password Lists] 
DLSUSRO2=C: \NET\DLSUSRO2. PWL 





[Domain List] 
ANYDOM01= 








Figure 68. NETWORK.INI file for DOS LAN Services and NetBIOS for TCP/IP 


NBTCP and native NetBIOS can run together in the same machine, but you must 
use separate logical adapters. The memory overhead of this configuration could 
be prohibitive in the DOS environment. 


If you are planning to run NBTCP and native NetBIOS (that is, LAN Support 
Program DXMTOMOD.SYS or DXMJOMOD.SYS), you must make sure that each 
program is using a different logical adapter. To change this for NBTCP, you 
must change the nb. 1lana_num entry in the [NETBIOS] stanza of 
TCPDOS\ETC\TCPDOS.INI. 
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All servers and requesters in a domain should use the same code page. 
However, Microsoft Windows supports only the ANSI character set while OS/2 
2.X and DOS support several code pages. The differences in code pages might 
cause some problems. 


To limit these problems, the DOS LAN Services requester in a Windows 
environment uses OemToAnsi and AnsiToOem conversion routines to convert 
data passed between Windows and non-Windows workstations. These 
conversion routines use tables supplied by Windows to map between the ANSI 
character set and the code pages supported by non-Windows workstations. 


Since DOS LAN Services does this conversion automatically, be careful when 
using the extended characters available through Windows. The conversion 
routines are sometimes forced to do an approximate conversion when the ANSI 
character does not exist in the OS/2 or DOS code page. The routines map to the 
closest character available when a correct mapping does not exist. 


For example, if Windows was installed with code page 437 and you are running 
with a domain code page 437, many of the diacritic characters available through 
Windows are not available in code page 437. The uppercase characters 


A-dieresis (A), A-acute (A), and A-grave (A) do not exist in code page 437 and 
are converted to the uppercase A by the AnsiToOem conversion routine. 


If Windows was installed with code page 850, the conversion routines use a 
different conversion table, and most of the diacritic characters are converted 
correctly. 
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Note: To avoid problems when using Windows, avoid using extended characters 
when sending messages, logging on, or displaying and accessing aliases. 


For the conversion routines to run correctly, load the same active code page in 
Windows that is loaded on the workstation. DOS LAN Services supports 
conversion tables for the following OS/2 and DOS code pages: 


> 437 
* 850 
+ 860 
* 863 
* 865 
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Chapter 5. Peer Services 


The peer service feature for OS/2 workstations was introduced with OS/2 LAN 
Requester 3.0. OS/2 LAN Server 4.0 now extends the peer service to DOS 
requesters as a feature of the DOS LAN Services component. This chapter 
describes both the DOS LAN Services and OS/2 LAN Requester peer functions 
provided with OS/2 LAN Server 4.0. 
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Figure 69. Peer Services 


Software Prerequisites 


The peer service is an installation option for both the DOS LAN Services and 
OS/2 LAN Requesters. Therefore, the software prerequisites are the same for 
the peer service as they are for these LAN Server components. To summarize, 
the following are required: 


DOS LAN Services Prerequisites 
IBM/MS-DOS 3.3 or 5.0; MS-DOS 6.0 or 6.2; IBM DOS 6.1 or 6.3 


DOS LAN Services and LAN Support Program 1.36 diskettes (shipped with 
the OS/2 LAN Server 4.0 package) 


OS/2 LAN Requester Prerequisites 
OS/2 2.0 or later 


OS/2 LAN Requester 3.0 diskettes or later (shipped with the LAN Server 
package) 
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Overview 


The peer service is a feature that provides a requester with some of the 
capabilities of a LAN Server. This was originally available as a feature of the 

OS/2 LAN Requester, part of the LAN Server 3.0 package. With OS/2 LAN Server 
4.0, it has been extended to be a feature of DOS LAN Services requesters. 


Once installed and configured, access to the requester's resources is no longer 
restricted to the user of the requester. The user, or an administrator on behalf of 
the user, may share the resources at a workstation so a user at another DOS or 
OS/2 requester may access the peer server resources. 


The peer service enables a user to share multiple directories, one printer queue 
(OS/2), and one communications device queue (OS/2) with other users on the 
network. DOS LAN Services requesters have the capability of sharing multiple 
printer and communications ports. The peer service differs from an OS/2 LAN 
Server in that only one user at a time may create a session with the peer server. 


Note: The peer server name is the same as the requester name. 





Installation 


The peer service is available as an option at installation time for both DOS and 
OS/2 LAN requesters. The peer service may not coexist with the LAN Server 
service on the same workstation. 


DOS LAN Services Peer Service Installation 


The peer service is automatically selected to be installed when you install DOS 
LAN Services. If this option was deselected when DOS LAN Services was 
originally installed, it may subsequently be installed by running INSTALL.EXE and 
selecting Install Peer Services. 





Figure 70. DOS LAN Services Peer Service Installation 


The follwing is a typical NETWORK.INI file for a DOS peer server: 
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[network] 
computername=DLSREQO1 
lanroot=C:\NET 
autostart=full,peer 
dospophotkey=N 
guiconfig=0,0,1 
username=DLSUSRO1 
domain=DOMAIN_A 
1lslogon=no 
reconnect=yes 
passwordcaching=yes 








[Peer] 
openmode=3 
xmitsize=4096 


[Password Lists] 
DLSUSRO1=C: \NET\DLSUSRO1. PWL 














Figure 71. DOS LAN Services Requester Peer Server NETWORK.INI 


Details of the NETWORK.INI [peer] parameter values are listed in “NETWORK.INI 
File Peer Parameters” on page 108. 


OS/2 Peer Service Installation 


To install the peer service on an OS/2 requester, you need to select the Tailored 
installation path. The peer service requires the LAN Requester service to be 
installed. If the LAN Requester has previously been installed, you may start the 
peer immediately following installation. 


Toa change the install action, select the comperents you want and 
then select a pushbutton below. 


Installed 
a ee 
ault Tolerance Administration Not installed : 
of LAN Services Installation’ C: Installed 
raphical User Interface Installed i 
S/2 LAN Applications Developm Not installed 2 


ser Profile Management Installed 
irst Failure Support Technolo Not installed 


After all changes are made, gelect UK, 





Figure 72. OS/2 Peer Service Installation 
When installing the peer service on an OS/2 workstation, you must decide on the 


level of security that you wish to use. See “Peer Server Security Considerations” 
on page 103. 
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Selact the security mode to be used by the 
Peer services, 


ig: User Level 


Guner's user [De : 


i" 


Cancel ; | 


eat 





Figure 73. Selecting the OS/2 Peer Services Security Mode 
The OS/2 peer service consists of three modules which are installed in the 
\IBMLAN\SERVICES directory. They are: 


* NETPSERV.EXE 
+ NETPSINI.EXE 
«+ ADDSRVIN.EXE 


The requester's IBMLAN.INI file is modified as part of the peer service 
installation process. The following changes are applied: 


A [peer] section is added with the following contents: 





security = User 
username = OS2USR02 
auditing = no 
The following parameters generally do not need to be 
changed by the user. NOTE : srvnets= is represented in 
; the server info struct as a 16-bit lan mask. Srvnet names 
; are converted to indexes within [networks] for the named nets. 

guestacct = guest 

autodisconnect = -1 

maxauditlog = 100 

maxchdevjob = 2 

maxchdevs = 1 

maxconnections = 26 

maxlocks = 64 

maxopens = 128 

maxsearches = 50 

maxsessopens = 80 

maxsessreqs = 25 

maxsessvcs = 1 

maxshares = 16 

maxusers = 5 

numbigbuf = 4 

numfiletasks = 1 

numreqbuf = 10 

sizreqbuf = 4096 
; The next lines help you to locate bits in the srvheuristics entry. 
; 1 2 
: 012345678901234567890 

srvheuristics = 111101411113110013311 

SRVSERVICES = 

srvnets = NET1 























Figure 74. OS/2 Requester Peer Parameters 


The following line is added to the [services] section: 


peer = services\netpsini.exe 
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Note: Logon verification is also modified by setting the requester wrkheuristics 
digit 37 to validate logons locally. “User Profile Management and OS/2 Peer 
Services” on page 111 discusses User Profile Management (UPM) 

considerations for the peer service. 


The IBMLAN.INI [peer] parameter values are discussed in “IBMLAN.INI File Peer 
Parameters” on page 110. 





Starting the Peer Server 
Before you can share resources, you must first start the peer service by running 
the command NET START PEER. This command also starts the requester if it is 
not already running. You may wish to start the peer service automatically when 
you log on by adding peer to the autostart parameter in the NETWORK.INI file for 
DOS LAN Services requesters or to the wrkservices parameter in the IBMLAN.INI 
file for OS/2 requesters. 


Setup Procedures 
This section describes the procedures that the owner of the peer server needs to 
follow to set up and administer the peer server. We look at the DOS and OS/2 
peer services setup procedures separately, since there are additional 
considerations for OS/2 peer servers. 


Setup Procedures for DOS Peer Services 
The DOS peer server may be setup either via the DOS LAN Services graphical 
user interface, Windows graphical user interface, or via the command line 
interface using the NET SHARE command. From the graphical user interface, you 
have the option to share resources by either selecting the appropriate icon or 
menu bar item. As previously discussed, you may share multiple directories, 
printer ports, and communications device ports. This is achieved via one of the 
two menu options, depending upon what resources you wish to share. Setting up 
a DOS peer server in a Windows environment is discussed in the next section. 


To share a directory, type a network name and 
directory, then select Add_ 





-— New Share 
Network name: 123_W0RK 














Directory: C-\DATASWORK 











Description: DLSREGB.B1 Shared 1-2-3 Data Files 


Password: 


Access permission: [>] Read Create 






































To delete, select one of the shared directories below, 
then select Delete. 





Shared directories on your workstation: 
C_DRIVE cis DLSREQH1 C: [9 
DOCS C:SDATASDOCS DLSREQB1 Shae 








Figure 75. DOS Peer Shared Directory Setup Screen 
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The same results may be achieved by typing the following commands at the DOS 
prompt: 








NET SHARE C_DRIVE=C:\ cdrvpwd /r:"DLSREQO1 C: Drive" /p:RWC 
NET SHARE DOCS=C:\DATA\DOCS docpwd /r:"DLSREQO1 Shared Doc's" /p:R 
NET SHARE 123_WORK=C:\DATA\WORK 123 /r:"DLSREQO1 Shared 1-2-3 Data" /p:RC 






































Figure 76. Sharing Peer Server Directories from the Command Line 


To share a printer, type a network name and select a 
print device, then select Add. 





-— New Share 
Network name: INKJET1 











e@ Device: Eg 
SSescription: 4879 attached to DLSREG@1L 


Password: 


Form feed: Cives CNo (@) Auto 























To delete, select one of the shared printers below, then 
select Delete. 





Shared printers on your workstation: 


LASERL LPTi 4039-10R at (2 
PLOTTERL CoML HP 7558 attaz4 














Figure 77. DOS Peer Shared Printer Setup Screen 


The same results may be achieved by typing the following commands at the DOS 
prompt: 





NET SHARE LASER1=LPT1: laslpwd /r:"4039-10R attached to DLSREQO1" 
NET SHARE INKJET1=LPT2: inklpwd /r:"4079 attached to DLSREQO1" 
NET SHARE PLOTTER1=COM1: plotlpwd /r:"HP 7550 attached to DLSREQO1" 












































Figure 78. Sharing Peer Server Printers from the Command Line 


For details of the enhancements to the NET commands in relation to the peer 
service and full syntax of the NET SHARE command, refer to “Extensions to NET 
Commands” on page 106. 


Setup Procedures for DOS Peer Services in a Windows Environment 


102 


When DOS LAN Services is installed on a Windows workstation, you may use the 
DOS LAN Services Windows graphical interface or, to further simplify the sharing 
of directories, use the Windows File Manager. With the peer service started, a 
Share directory menu item appears in the File Manager Disk pull-down. 


Selecting a directory in File Manager and selecting this option displays the DOS 
LAN Services Share Directory window with the selected directory appearing in 

the Directory field as shown in Figure 79 on page 103. Complete the remaining 
fields and select Add to make files in this directory available for users to access. 
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Note: This option is available as the default. Whether or not the option is made 
available to users is controlled by the DOS LAN Services Configuration Window 
as shown in Figure 55 on page 80, which is accessed by selecting the Network 
icon in the Windows Control Panel program group. This program also enables 
and disables logon at Windows startup and warning messages when the network 
is not started. 





[ New Share 


Network name: 





Directorp: 





Description: 


Password: 





Access permission. [] Read Dd Write [*] Create 








Shared directories on your workstation: 








Figure 79. DOS Peer Shared Directory Setup Screen (Windows) 


Setup Procedures for OS/2 Peer Services 
In this section, we look at the setup procedure for the OS/2 peer server and see 
how a requester then accesses the resources shared at the peer server. Before 
beginning, you need to decide which peer server security option you are going 
to adopt. The following section describes the differences between share and user 
level security modes and presents the advantages and disadvantages of each to 
assist you in making your decision as to which best suits your environment and 
business requirements. 


Peer Server Security Considerations 

When installed on OS/2 requesters, the peer service can be used in either share 
level or user-level security mode. You configure the peer service security mode 
through the OS/2 LAN Requester installation program as illustrated in Figure 73 
on page 100. You may also change the security mode by editing the security= 
parameter, which is the first line in the [peer] section of IBMLAN.INI, to read 
security=User or security=Share. 


User-Level Security: User-level security controls access to resources shared by 
the peer server by identifying users with a user ID and a password. LAN Servers 
use this form of security, which is the default security mode for OS/2 peer 
services. 


The advantages of user level security are: 


You may define specific access rights to a resource for an individual user or 
a group of users. 
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If a user's user ID and password are kept the same on the peer server as 
they are on the domain, user-level security provides seamless access for the 
user. 


The disadvantages of user-level security are: 


+ Since user IDs must be created and maintained, there is more of an 
administrative burden attributed to user-level security than share-level 
security. 


+ If users want to access the peer server and domain with the same user ID 
and password, they must change their password at the peer server each 
time their domain password changes. 


Note: Since Network SignON Coordinator/2 is shipped as part of LAN Server 
4.0, this disadvantage has been addressed. Refer to Appendix B, “ Network 
SignON Coordinator/2” on page 433 for more information. 


Share-Level Security: Share-level security allows the owner of the peer server 
to specify both the password and permissions associated with a shared resource 
(not with the user) . 


Note: The DOS LAN Services peer service controls access to resources through 
the implementation of share-level security only. 
The advantages of share level security are that: 


Owner does not need to create a user ID for each user that accesses the 
shared resource. Users only need to know the fully qualified network name 
and password associated with the resource. 


No separate access control needs to be created for subdirectories. This is 
controlled by the share permissions. 


Both of these factors make share-level security easier to administer than 
user-level security. 


The disadvantages of share-level security are: 


+ While administration is easier, access control is less flexible and there is no 
distinction between types of users. They all get the same level of access. 


* For a shared directory, access control extends to the entire directory 
contents. You are unable to restrict access to specific subdirectories. 


Note: This problem may be overcome by sharing individual directories. 


If a user is connected to your peer server, the owner cannot connect. With 
user-level security, the user ID specified by the username= parameter in 
IBMLAN.INI can always connect. 


+ If the IPC$ resource is not shared or is shared with a password on a peer 
server using share-level security, the OS/2 Workplace Shell cannot display 
resources at the server, and resources at the server shared with a password 
do not display. 


To summarize, the advantages of one security mode may be a disadvantage of 
the other, depending upon individual requirements. 
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Administrator Considerations 

Administration of an OS/2 peer may be achieved both locally and remotely via 
the OS/2 LAN Requester graphical user interface or command line interface. In 
order for a user to administer an OS/2 peer server, the user must be defined as 
an administrator in the peer server's local user accounts database. This is 
achieved through User Profile Management (UPM) or by executing the following 
NET command at the peer server: 





T, 


NET USER P 











‘—ERUSR1 PEERPWD /ADD /PRIV:ADMIN 









































Tr 


where the new administrator ID is PEERUSR1 with a password of PEERPWD assigned. 
If the peer server is using share-level security, the user may connect to the 

ADMIN$§ share at the peer server to perform administrative functions. If using 
user-level security, the user may connect to the IPC$ share at the peer server to 
perform administrative functions by issuing the command: 






































NET ADMIN \\peerservername password /C net command 





where net command is the command that you would like to issue at the peer 
server. 


Note: Do not share IPC$ at the peer server with a password; otherwise, the 
peer server will not be visible through the network folder. 


Typically, the owner of a peer server is defined as an administrator on the peer 
server and as an ordinary user on the domain. The command line interface 
allows users defined to the domain with no administrative capability to have 
access to administrative interfaces for administering their peer servers. Because 
the peer server is not part of a LAN Server domain, it cannot be administered 
from the LAN Server, which makes it difficult to administer centrally. 


Note: Remote administration of a DOS peer server is not possible since DOS 
LAN Services clients do not have a local user accounts database. 


Interprocess Communications (IPC$) Considerations 
IPC$ should be shared at the peer server if a peer server administrator needs to 
access the peer server from a remote workstation. 


There is no limit on the number of users who can use the peer server's IPC$ 
resource. This resource allows users to run the NET ADMIN command from a 
remote workstation to administer the peer server. Also, IPC$ allows multiple 
users to access distributed applications that use named pipes and mailslots on 
the peer server. 


Note: IPC$ is applicable to OS/2 peer servers only. 





Overcoming the Single Session Limitation 


As previously mentioned, only one user at a time may access a resource at the 
peer server. There is, however, a circumvention for printer resources whereby 
you access a peer server's shared printer resource from a LAN Server and 
share this resource (as a virtual printer attached to the server) again from the 
LAN Server to provide multiple requesters with access. 


The following describes a step-by-step way, with the aid of a graphical 
representation of the scenario, to overcome this limitation: 











1. Issue a NET SHARE command at the peer server for the printer resource: 
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NET SHARE LASER1=4039-600 














You must specify the printer object name defined on the OS/2 Desktop, such 
as 4039-600 in this case. For a DOS LAN Services peer server you would 
specify the port that the printer was attached to in place of the printer object 
name. 


2. LOGON to the domain at the LAN Server that is to share the printer 
resource. 














3. Access the peer server's shared printer by issuing a NET USE command (in 
this scenario the name of the peer server is OS2REQ02): 








NET USE LPT3: \\OS2REQ02\LASERI1 




















4. Issue a NET SHARE command at the LAN Server to share this resource: 














NET SHARE LSLASER1=LPT3 











5. Now any LAN Requester workstation on the network can access the shared 
printer resource at the peer server via the LAN Server by issuing: 








NET USE LPT1: \\SERVER_A\LSLASER1 




















The following figure outlines this scenario: 









LAN Server 


Com putername=0 S2REQO2 
% ie 1.3.2.0, 3.0 0r4.0 











om puternam e=SERVER_A 


NET USE LPT? \OS2REQ O2\WLASER1 


ET SHARE LASER 1=4033-600 


08/2 LAN Requester NET SHARE LSLASERI=LPT3 


(Peer Server) 





NETUSE LPI NWSERYER_ANLSLASERI 
pe 


OsfeorDOs 


Requester 











Figure 80. Printer Redirection of Peer Server via LAN Server 


Note: The above scenario is also applicable to DOS LAN Services requesters. 
You must also note that, because the LAN Server has a connection with the peer 
server, no other requesters may access any of the peer server's other 

resources. 


Extensions to NET Commands 


The NET commands are enhanced in the following manner (command syntax 
variations between DOS and OS/2 peer servers are noted): 














--NET START PEERFcomputername] -- [options] --------~----------------------- 





This starts the peer service and the requester service, if the latter has not 
already been started. The computername parameter specifies the name of the 
peer service machine, and options are identical to the server service NET 
START, except that /autodisconnect must be -1. Any other value for 
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autodisconnect results in an error message informing you that an illegal 


value was entered for the parameter. 


Note: For DOS LAN Services peer servers, computername is not a valid entry, 


and the only option available is /Y1 





* 
ES. 


It executes the command 


without prompting for information or confirmation of actions. 





--NI 





ET PAUS 





Tr 


PE 








ER--------------- 








This pauses the peer service. 


Note: This command is not applicable to DOS LAN Services peer servers. 








--NI 





ET CONT 





NUE 





PE 








ER------------ 





This resumes the peer service after it has been paused. 


Note: This command is not applicable to DOS LAN Services peer servers. 





=SNI 





ET STOP PE 








ER-- --------- 








This stops the peer service. 





--NI 








ET SHAREnetname=resourd@assword-/us (ers) 





:n]------- 





--[/re(mark) : "text {Ypermissions: [XRWCDA] ] ----- 





This is identical to the server NET SHARE with the following exceptions: 


If the resource is not an IPC share, /users:n (if n > 2) and /unlimited will 
both generate errors stating that an invalid value or option was entered. 


If an attempt is made to share a second communications port or printer 


queue, you will be informed that you have attempted to add an item that 
exceeds the maximum allowed. (These limitations apply to OS/2 peer 


servers only.) 


* The password and permissions parameters are only valid with a peer 
service share since the LAN Server service only runs in user level 


security mode. 


Notes: 


1. The /users parameter is not applicable to DOS LAN Services peer 
servers. The permissions applicable to DOS LAN Services peer server 
resources are limited to R(ead), W(rite) and C(reate). An additional 
option, /PRINT, identifies a shared resource as a DOS LAN Services peer 
server printer queue, and there are options to control how output is 








Tr 


handled via the /FORMFE 














'D parameter. 


and remarks fields are 12, 8, and 48 alphanumeric characters, 


respectively. 





- -NET V 











. The maximum allowable lengths for the NET SHARE resource, password, 





EWA \peersrvname-- - 





This allows the 


requester to view the shared resources on the peer server. 


Note: This command is not applicable to DOS LAN Services peer servers. 
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—NET USE, devicename]\computername\netrdmessword -/comm] 





The password parameter is typically used for share level security and to 
secure DOS LAN Services peer server resources. 


--NET STATS PEER----- 











T 














The NET STATS command accepts the peer service parameter as an option to 
produce statistics about the peer server in the same format as requester and 
server statistics are reported. 


Note: This command is not applicable to DOS LAN Services peer servers. 





- -NET CONF 











G PEEReptions] 7 = = 








The results of this command are the same as for the server, except that the 
Server Level reported is Peer Server. Idle Session Time is always -1, and if 
specified, the /autodisconnect parameter must equal -1. 





- -NET SESS 


























ONY\ comput ernaméPEER---- - 





The /peer option, introduced in LAN Server 3.0 allows ordinary users at 
workstations to see who is using the peer server. The /peer option displays 
the computer name, user name, and idle time of all users that have a 
session to the peer server. 


This command is, therefore, of particular use to users that wish to know who 
currently has access to a peer server so that they may ask the user when 
the connection will be free. 


Note: This command is not applicable to DOS LAN Services peer servers. 





NETWORK.INI File Peer Parameters 


If the [peer] section of the NETWORK.INI is not visible, the default values apply. 
Table 7 provides detailed descriptions of the parameters in the NETWORK.INI 
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[peer] section. 


Table 7 (Page 1 of 3). NETWORK.INI Peer Section Parameter Values 





Parameter 


Description 


Valid Values 


Default 
Value 





a20monitor 


numshares 


numreq 








Saves the state of the A20 line 
during task switching. Some memory 
managers fail when this parameter 
is set to 1. If you experience system 
hangs with your memory manager, 
set this parameter to 0. 


Indicates the maximum number of 
resources you can share. 


Indicates the number of request 
buffers the peer service will use 
when it starts. 





Oto 1 


2 to 256 


3 to 6 





1 


10 
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Table 7 (Page 2 of 3). NETWORK.INI Peer Section Parameter Values 











Parameter Description Valid Values Default 
Value 

xmitsize Indicates the size, in bytes, of the 512 to 2048 

transmit buffers the peer service will 32768 

use when transferring data. 

Note: numreg * xmitsize < 48 KB 
tasktimeslifedndicates the amount of time (ticks) 00 to 99 54 

the foreground and background will 

each run. Format: TimeSlice=FB. 

The default for the foreground is 5, 

and the default for the background 

is 4 (TimeSlice=54). 

Value ‘Ticks 

0 2 

1 4 

2 6 

3 10 

4 14 

5 22 

6 30 

7 42 

8 56 

9 72 
openmode Indicates the mode in which files will O0to3 3 


be opened when an open request is 
received. 


0 


User Open mode requested 
by the application that is 
running 


DENY-NONE sharing mode if 
read-only access is granted 
to .EXE or .COM files 


COMPATIBILITY-MODE for 
.BAT files or if write access 
is granted to .EXE or .COM 
files 


DENY-NONE sharing mode if 
read-only access is granted 
to .EXE or .COM files 


DENY-WRITE sharing mode 
if read-only access is 
granted to .BAT files 


COMPATIBILITY-MODE for 
.BAT files or if write access 
is granted to .EXE or .COM 
files, or .BAT files 


DENY-NONE sharing mode 
on all compatibility mode 
opens 
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Table 7 (Page 3 of 3). NETWORK.INI Peer Section Parameter Values 





Parameter Description Valid Values Default 

Value 
fileshare- | Indicates the bytes allocated for the 512 to 2048 
size DOS storage area used to record 32768 


file-sharing information. 





sharelocks | Defines the maximum number of 20 to 1000 20 
active locked ranges in files that you 
can share with the peer service. 


fmshare Indicates whether you want to be Yes, No Yes 
able to share directories from the 
Windows File Manager. 


spooldir Indicates whether you want your Any local C:\NET 
spool files to be stored. This allows drive and 
you to store your spool files directory 


somewhere other than the network 
directory. RIPL machines need to 
have this parameter to print using 
the peer service. 














Notes: 


1. The tasktimeslice and openmode parameters may be changed dynamically on a 
DOS LAN Services peer server with the following commands: 





NI 
N 


T CONFIG /TIMESLICE: FB 
T CONFIG /OPENMODE : X 








Hw 























2. If SHARE.EXE is started before the peer service, the values for these parameters 
are those specified when SHARE.EXE was started. 


3. These parameters must be manually added to NETWORK.INI to change their 
default values since the installation program does not automatically add these 
parameters. 


4. If you specify the different location for spool files, you must copy the file PQ.SPL 
from the network directory to the directory specified. Otherwise, the peer 
service will fail to start because the print server component requires this file. 











IBMLAN.INI File Peer Parameters 


The [peer] section of the OS/2 peer server IBMLAN.INI contains the same 
parameters as the [server] section with the following additional parameters: 


The security parameter, discussed in detail earlier in this chapter, specifies 
the security mode the peer server is using. 


The username parameter specifies the user ID of the peer server owner. This 
parameter is only relevant if the peer server is using user-level security. 

The specified user ID is granted a session with the peer server regardless of 
whether or not other workstations have a session established with this peer 
server. This ensures that the owner can always connect to their peer server. 
This parameter is ignored if the security parameters specifies a security 
mode of share. 


Note: If a resource is shared with the /users:1 option, this limit is enforced 
and, in this instance, the owner would be unable to connect to the resource if 
it was already in use. 


Neither of these parameters are valid for LAN Servers; they only apply to OS/2 
peer servers. 
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User Profile Management and OS/2 Peer Services 


User Profile Management (UPM) can be used to manage user access to 
resources that are being shared on an OS/2 peer server. UPM has the ability to 
administer the local peer server as well as provide the normal functions to a 
LAN Server. 


When the peer service is installed, IBMLAN.INI is modified to specify that the 
user's logon is verified against the local user accounts database. This change 
means that when you log on, the password verification is performed locally, and 
a session is established with the OS/2 peer server. 


As most users on a peer workstation also require access to a LAN Server, this 
verification can be changed. The only OS/2 LAN Server procedure requiring 
local logon is UPM management for the local peer server shares. You can 
connect to your local UPM even if you only have domain logon verification 
(provided your user IDs and passwords are the same locally and on the domain). 
If you have installed the peer service but want the domain logon to be your 
default rather than the local logon: 


1. Change the value of digit 37 of the wrkheuristics parameter in the 
[requester] section of IBMLAN.INI from 1 (verify against local NET.ACC) to 2 
(verify against domain NET.ACC). Keep your user IDs and passwords the 
same both locally and on the domain. 


2. When local UPM changes are required, double-click on the UPM icon and 
from the Actions selection, choose Use domain... as shown in the following 
screen: 





Change 
Change password... 


Select groups for user ID... ‘ator 
se domain... ar Number 2 


SS ROD cence eeeee eee eeesseeeseessenenennesesnnenaenranesnane 


| Password is required 
Password last changed 1 days ago 
: Access is allowed 





3. The Use Domain selection panel is displayed. Select Local for your local 
UPM (here you can also select New to specify another domain). 





Current domain: aNYDOME1 





Rl ctel OR elas eee 
“a Local 
# New 





Chapter 5. Peer Services 111 


The user definitions can now be performed using the same process as for 
domain user definitions. 





Change user comment... 
Change password... 
Select groups for user ID... 
Add/Change user logon profile... 
Erase user logon profile... 

e domai 





Note: The local UPM panel also provides some options for managing remote 
node logons. Remote nodes are remote workstations or remote resource 

names. Node names of database nodes, 5250 Emulation partner LU alias names, 
and SNA APPC transaction program LU aliases are all remote nodes that you 

can define logon profiles for. 


The logon profile provides automatic logon to the remote node when you logon 
at the workstation. 
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Chapter 6. Command Line and API Enhancements 


The purpose of this chapter is to describe enhancements to the commands in 
OS/2 LAN Server 4.0 available from the OS/2 and DOS command prompts. 
Additional parameters for existing commands are discussed as well as the new 
commands NET APP and NET DASD. In addition, an overview of extensions to 
the LAN Server APIs is given. 


The aim here is to provide an overview and quick reference for what has 
changed. For a full description of the LAN Server commands, see the Commands 
and Utilities Reference. The reference has been redone and not only includes the 
new commands but also has more detail on the other commands (for example, 
the implication of commands on Peer servers is explored in more detail). Fora 
full description of the LAN Server APIs, see the Programming Guide and 
Reference. These references are available online in the LAN Server Books 
container which can be found in the LAN Services container. Use the LAN 
Installation program to install the references if they were not installed previously. 





Introduction to LAN Server Commands 


In LAN Server 4.0, all tasks that were available through the LAN Server 3.0 
full-screen interface can be achieved through commands and/or APIs. 


With the introduction of the new, powerful graphical user interface (GUI) to LAN 
Server you may wonder when you might gain more from using the commands. 
You might use the command-line interface instead of the GUI to perform LAN 
Server functions if you: 


* Are familiar with IBM networks and the OS/2 LAN Server commands 


* Are comfortable typing commands without the help information provided with 
the graphical user interface 


- Want to create command (.CMD) files for network functions 


The remainder of this section provides a number of notes and hints about using 
LAN Server commands. 


Implications of Local Security 
If local security is installed on a server, specific operator privileges are required 
in order for most of the commands to complete correctly. These are listed in 
table 3 of the Commands and Utilities Reference (in the Local Security on 386 
HPFS Servers section). 


Getting Help for LAN Server Commands 
Remember that, besides the reference manuals, quick help can be obtained for 
most LAN Server commands and utilities through the NET HELP command. 
Examples of ways to use this command include: 





NET HELP 











This lists all commands and utilities for which help is available as well as the 
format of the NET HELP command. 
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NET HELP command 
or 
NET HELP utility 



































This format describes the NET command (for example NET HELP USER) or utility 
(for example NET HELP FTMONTIT) that is entered. 




















NET HELP command /OPTIONS 
or 
NET HE 








Tr 














iP utility /OPTIONS 








The /OPTIONS parameter causes information to display for each parameter that 
can be used for this command or utility. 


Note: The help command can be used to get help for options on the NET HELP 
command itself: 





NET HELP /OPTIONS 














Creating Command Files 


You can combine commands to create command (.CMD) files that simplify 
routine tasks, eliminate repeating tasks, and personalize commands to your 
environment. 





Some commands allow you to eliminate confirmation prompts by including /YES 
or /NO as a parameter. These parameters suppress the prompt and let you put 
commands in a command file that runs without interruption. 


lf REXX support is available (it is usually installed in OS/2 by default), you can 
make the command files more complex and functional with REXX facilities. OS/2 
provides the online OS/2 REXX reference manual to give further information on 
writing REXX procedures. 


Rules for Processing Command Parameters 
Here are some rules you should be aware of: 


For most commands, parameters are read from left to right. 


Generally, duplicates of parameters are allowed. Where parameters conflict, 
the last parameter (to the right) overrides previous ones. 


Unless otherwise noted in the description of a command, the order of the 
parameters is not significant. However, the use and positioning of spaces 
and other special characters can be important. If in doubt, use the NET HELP 
command or see the Commands and Utilities Reference. 


* When you type a command without parameters, current information, 
depending on the user type entering the command and related to the 
purpose of the command, is listed. For example, typing NET ACCESS as an 
administrator at the server with no parameters lists all the access control 
profiles on the server. 














General Considerations 


There are a number of items to be aware of regarding the usage of new 
command functions, especially in a domain of mixed LAN Server levels. 


Cross-level command usage 


As OS/2 LAN Server 4.0 introduces a number of capabilities not available in 
previous releases, it is important to be aware of the effect of using 4.0 
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commands to administer servers, users and so on from releases prior to 
version 4.0. 


DOS LAN Services adds many commands and parameters previously only 
available to OS/2 machines. However, certain functions cannot be fully 

supported by previous release servers. For example, using NET ALTAS 
aliasname to display information for an alias of an OS/2 LAN Server 3.0 

resource is not possible and returns Access Denied even though the user 

may have the correct access. NET ALIAS aliasname to an OS/2 LAN Server 4.0 
resource does work correctly. 





























Extended user-ID lengths 


OS/2 LAN Server 4.0 increases the maximum number of characters allowed 

in a user ID to 20. While a 20-character user ID can be verified by a LAN 

Server 4.0 to access resources, an adapter allows only up to 15 characters 

for a message name. A user ID of more than 15 characters cannot have the 

ID added as a message name during logon. Other users, therefore, are 

unable to use NET SEND username to send messages to that user ID. However, 
they can still send messages to the machine ID, or to another name 

registered by that user with the NET NAME messagename command. 





























+ DIR commands with directory limits 


The DIR command is now subject to directory limits. If the command is 
performed against a directory that is subject to directory limits, the bytes 
free value is a function of the limits and does not display the rea/ amount of 
free space on the drive. If the directory is not subject to directory limits, the 
DIR command works as expected and returns the actual amount of free 
space on the drive. 


This function has limitations: 


1. The bytes free value reflects the drive's real physical amount of free 
space if one of the following holds true: 


- The operation is made against a local drive. 


The operation is done by an administrator. 


The operation is made against a FAT drive. 


The operation is made against an HPFS386 drive, but there are no 
limits placed on the directory or on any of its parent directories. 


2. The bytes free value reflects the free space as specified by directory 
limits when all of the following hold true: 


- The operation is performed against a redirected drive. 


The directory on the server resides on an HPFS386 drive. 


- The HPFS386 drive is enabled for directory limits. 


The operation is made on behalf of a user ID that is not an 
administrator. 


- There is at least one limit applied anywhere along the directory's 
path. 


The limitation to this support is that the bytes free value on a shared 
directory is always equal to the available space for that user. For example, 
let's say that a user (not an administrator) has redirected drive Z: mapped to 
E: IBMLAN USERS MYHOMEDIR. The directory has a directory limit applied 
to it. When the user types in the following commands, they all return the 
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same amount of free bytes. This is the amount of free space at 

E: IBMLAN USERS MYHOMEDIR that is available for the user, but is not the 
physical amount of free space for the directory (which is what an 
administrator would see displayed). 





Z:> DIR 

C:\> DIR Z:\ 

C:\> DIR Z:\PUBLIC 
C:\TMP> DIR Z: 
Z:\PUBLIC> DIR Z:\PUBLIC 



























































Changed and New OS/2 Commands 


NET ACCESS 


This is an alphabetic list of all commands for which alterations have been made. 
See “New Commands Table” on page 124 for a table summarizing the new 
commands and parameters. 


You can use a subset of the OS/2 LAN Server 4.0 commands to perform tasks 
through DOS LAN Services (DLS) from a DOS workstation. The “Changed and 
New DOS LAN Services Commands” on page 129 section lists new commands 
available under DLS. 


The NET ACCESS command has the significant addition of the /APPLY. 
parameter. This performs an apply of the access control for the specified 
directory to all the subdirectories under it. 


NET ACCESS can also be used with an alias name now and not just a resource 
name. 


Use the following form of the command to list permissions for a resource or 
alias: 











--NET ACCESS- - -resource- ne ae - aecarices FuLs = 











-alias---- -/TREE- 
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Use the following form of the command to modify permissions for a resource or 
alias: 








--NET ACCESS- - -resource- - = = 
alias--- /ADD--rights---------- 
- /CHANGE--rights------- 
-/GRANT--rights-------- 
- /REVOKE--name 
























































































































































-/APPLY-- 

— /DELETE- ---- - 

-/TRAIL: YES-- ---- 

-NO-- | 

-/FAILURE: - -OPEN--— 
-WRITE-- | 
-DE IETE- | 
-ACL---- | 
a ee | 
-NONE--- | 

-/SUCCESS: - -OPEN--— 
-WRITE-- 
-DE ETE- 
-ACL---- 
-A sb--- 
-NONE--- 











When you type NET ACCESS without parameters, a list of access control profiles 
and associated permissions is displayed. Refer to “New Commands Table” on 
page 124 for a description of the parameters. 








NET APP 
NET APP creates, deletes, changes, and displays information about public and 
private network application definitions. All the parameters required to set up or 
alter an application are included, such as the application's ID, working directory, 
drive assignment, and so on. 


The NET APP command requires a number of steps to be performed before the 
application can be defined: 
Install the application. 
Use the NET ALIAS command to create aliases for the directory that contains 
the resources and any other network resources that the application requires. 
+ Use the NET ACCESS command to assign access permissions for the alias 
defined. 


Use the NET USER command to add the applications to the user's program 
starter (Network applications folder for OS/2 or the applications list for DOS 
and Windows requesters). 


In addition: 
The NET APP command only works in domains of OS/2 LAN Server 3.0 or 
higher. 


If a local path is specified in /APPDIR or /WRKDIR, that local path must exist 
on every workstation where the application will be run. The NET APP 
command warns you of this fact. 
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Use the following form of the command to list public or private applications: 





--NET APP -----— ------ 
-/PRIVATE: userid -/DOMAIN: name 


























Use the following form of the command to add a public or private application: 











--NET APP--appid--/ADD ee Beis 





























































































































-OS2- | -/PRIVATE: userid 
-/TYPE: - -DOS—- 
—-/REMARK:"text" -—/COMMAND:"text" -/APPDIR: alias > 
| -\rempath | 
-localpath----------- 
-/WRKDIR: - -alias - — | ; 
| -\rempath | -/ASSIGN- ---device: alias- 
-localpath----------- -*:alias ----- 
-/DOMAIN: name -/APPDRIVE: - -d:—- -/WRKDRIVE: - -d:—- 
=: Se 
| -PM-- || -N- | 
-/INTERFACE: - -FS- / PROMPT: - -Y-- 
-VIO- 


Use the following form of the command to change details of a public or private 
application: 








--NET APP--appid == = 





























































































































-/PRIVATE: userid -/REMARK: "text" 
-/COMMAND: "text" -/APPDIR: alias - —_ 
| -\rempath | 
=localpath-=ass8434=5= 
-/WRKDIR: - -alias- --------—- -/DOMAIN: name 
| -\rempath | 
“loca lpatha==-a=aeas— 
| ie cca | ' | 
-/ASSIGN--- -device:altias -/UNASSIGN--- -device:altas 
-*:alias ----- -*:alias ----- 
-/APPDRIVE: d+ /WRKDRIVE: - -d+— 
ae Ren. eo es. 
| -PM-- | | -N- | 
-/INTERFACE: - -FS-— -/PROMPT: - -Y- 
-VIO- 
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Use the following form of the command to display details about a specific public 
or private application: 





--NET APP--appid ~-----------—- ----- - ------- 
-/PRIVATE: userid -/DOMAIN: name 


























Use the following form of the command to delete a public or private application: 





--NET APP--appid--/DEL ae BoRvSe ees 




















-/PRIVATE: userid -/DOMAIN: name 




















If you use the NET APP command without parameters, it displays a list of all public 
applications defined in the logon domain. Refer to “New Commands Table” on 
page 124 for a description of the parameters. 


NET DASD 


The enhancements to HPFS386 in OS/2 LAN Server 4.0 allow you to restrict 
storage on network drives. See “Limiting DASD Space within HPFS386 
Directories” on page 218 for a further description of directory limits. 


NET DASD manages and displays directory limits. Using NET DASD, an 
administrator or user with P permission to a directory can impose a size 
limitation on that directory. 


Optionally, alerts can be sent to the administrator when a specified threshold, 
and also at regular specified intervals beyond the threshold, are met. For 
example, you can specify the threshold to be 80% of the limit with intervals of 
5%, so that alerts are sent at 80%, 85%, 90%, 95%, and 100% of the DASD 
limit. By default, these alerts are sent to any members of the ADMINS group (all 
administrators). Once the actual limit is reached, the user who is attempting to 
exceed the limit will receive a message stating that the operation was 
unsuccessful due to the directory limitation. 


Directory limits are not enforced for the following processes: 
* All processes initiated by an administrator 
+ Privileged local processes when local security is installed 
* All local processes when local security is not installed 


Note: Enabling directory limits on an OS/2 LAN Server 4.0 HPFS386 volume 
means that earlier versions of HPFS386, or ordinary HPFS, cannot access the 
volume, even when local security is not used. An OS/2 LAN Server 4.0 HPFS386 
set of boot diskettes is required to access such volumes if booting from diskette 
is required. For information on how to create the boot diskettes, see “HPFS386 
Boot Diskettes” on page 216 or the LAN Server Network Administrator Reference 
Volume 1: Planning, Installation, and Configuration manual. 
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Use the following form of the command to display directory limits: 








--NET DASD ------------— w---------------- 














directory _ 
-/TREE- 














Use the following form of the command to manage directory limits for volumes: 





--NET DASD--dr a lataneaiiliaiatatatatatatatatatatatatatiatatatatatatatatatatatatatate 

















- /ENABLE-- 
- /DISABLE- 
- /REFRESH- 



































Use the following form of the command to add a directory limit to a directory: 

















--NET DASD--directory--/ADD- -/MAX: nan - - - 











-/VAL: - ----— 
-YES- 
-NO-- 











-/THRESHOLB: n - = Seca 
-/INCREMENT+nn 























Use the following form of the command to change the directory limit of a 
directory: 














--NET DASD--directory--/MAX:nan 7 7 7 —_—- - - 














/VAL: /THRESHOLB:n 




















-/INCREMENT+nn 











Use the following form of the command to remove a directory limit from a 
directory: 

















--NET DASD--directory--/DEL- 7 - — - - - 























When you type NET DASD without parameters, a list of all directory limits that have 
been set on all HPFS volumes is displayed. Refer to “New Commands Table” on 
page 124 for a description of the parameters. 
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NET TIME 


The NET TIME command has an additional parameter that allows the domain 
date and time to be set from a workstation. The /DATE and /TIME parameters 
reset the date and time at the domain controller and also resynchronize all 
active servers in the domain to the same date and time. 


The synchronization of date and time between the domain controller and 
additional servers is important for services such as NETLOGON to function 
correctly. 


Use the following form of the command to display the current time at the primary 
domain or the specified domain: 





--NET TIME - 7 

















-/DOMAIN : name 








Use the following form of the command to display the current time at any server 
on the network: 














--NET TIME--\\servername - 





Use the following form of the command to synchronize the local clock with a 
remote server's or domain's clock: 





--NET TIME ---------- ----- —- 
-/SET-—/DOMAIN: name  — ------ 
-\\servername 





























Use the following form of the command to set the clock of the specified domain 
and synchronize the clocks of all active additional servers with that of the 
specified domain: 








--NET TIME ----- - - --------— --------- 
-/DATE: datestring -/TIME: timestring -/DOMAIN: name 















































When you type NET TIME without parameters, the time and date of the domain 
controller are displayed. Refer to “New Commands Table” on page 124 fora 
description of the parameters. 
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NET USER 


With the implementation of backup domain controllers in OS/2 LAN Server 2.0, 

the NET USER command gained an additional parameter, /LOGONSERVER. This 
determines how the user logon is handled by domain controllers and backup 
domain controllers in the LAN. This parameter is now documented in the 
Commands and Utilities Reference. See Chapter 12, “Backup Domain Controller” 
on page 275 for further details of the backup domain controller function. 


An additional parameter in OS/2 LAN Server 4.0 is /SCRIPT. This specifies a 
program (of extension .CMD, .EXE, .BAT or .PRO) which is run when the user 
logs on. This is in addition to the placing of a PROFILE.CMD/PROFILE.BAT in the 
IBMLAN\DCDB\USERS\username subdirectory. The program specified by 
SCRIPT is run first, and the PROFILE.CMD/PROFILE.BAT is run second. The 
SCRIPT parameter is a path continuing from the path specified by the SCRIPTS 
parameter in the netlogon section of the IBMLAN.INI file which defaults to 
C:\IBMLAN\REPL\IMPORT\SCRIPTS. 


Notes: 


1. As scripts are not contained in the DCDB, they are not automatically 
replicated to backup domain controllers. You need to manually copy them to 
all backups (either using the replicator, using an AT command or copying 
them to backup manually after changes) in order for the script to be run 
when a user ID is validated by a backup domain controller. 


2. Because scripts are also used in Microsoft LAN products, this added support 
enhances interoperability between Microsoft clients and OS/2 LAN Server. 
For more information on interoperability, see Chapter 9, “LAN Server 4.0 
Interoperability” on page 161. 


There is a significant new form to the NET USER command that allows logon 
assignments to be added and removed from a user name, using the parameters 
/ASSIGN and /UNASSIGN. 


The /PASSWORDEXP parameter available in OS/2 LAN Server 3.0 is now 
included in the online reference. 


Use the following form of the command to list user accounts: 





--NET USER-- 
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Use the following form of the command 





to add or modify a user account: 








































































































































































































--NET USER - - 
username - -/ACTIVE: = /ADD 
-password- -YES- 
BOE eee -NO-- 
~/PRIVILEGE: priv - /COUNTRYCODE =nnn -/PASSWORDCHG: - ----— 
-YES- 
-NO-- 
-/PASSWORDREQ: - ----— -/PASSWORDEXP: - ----— 
-YES- -YES- 
-NO-- -NO-- 
-/COMMENT : text -/USERCOMMENT: ext -/EXPIRES: - ----—- 
-date-- 
-NEVER- 
-/FULLNAME: name -/HOMEDIR: pathrame -/SCRIPT: pathname 
-/MAXSTORAGE: — ---------—- -/OPERATOR: list 
SHiseeseeee 
-UNLIMITED- 
-/TIMES: - -times- -/WORKSTATIONS: - - * -—-- 
—-ALL--- wou i ey 




















- /LOGONSERVER: 





-\\servername- 





AY 





Use the following form of the command to add assignments for a user: 











--NET USER--username--/ASSIGN--- -device:alitas-- - 
-PUBLIC: appid - 
-PRIVATE: appid 


























Use the following form of the command to delete a user's assignments: 








, 














--NET USER--username--/UNASSIGN--- -device:altas-- 
-PUBLIC: appid - 
-PRIVATE: appid 
-PUBLIC:ALL --- 





























-PRIVATE: ALL 





-LOGASN: Au] 


Ly 
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Use the following form of the command to remove a user account from the 


domain: 





--NET US 














AR--usernamne=— 





-/DEL 




















When you type NET US 
accounts in the domain is displayed. When you use this command at a 
requester or peer workstation, information is displayed about the local user 
accounts database. Refer to “New Commands Table” for a description of the 


parameters. 


New Commands Table 


Table 8 lists the new and altered commands for OS/2 LAN Server 4.0 and their 


parameters. 











ER without parameters at a server, a list of all user 





Table 8 (Page 1 of 5). New and Altered OS/2 LAN Server 4.0 NET Commands 


Command 


NET ACCESS 























Parameter New Function 

alias X Allows manipulation of resources by alias name 

name Identifies a specific user or group ID 

rights Specifies the name of a user or group as well 
as the permissions in the form 
name:permissions 

/TREE Reports access control profiles with associated 
permissions for the specified resource and all 
its subdirectories 

/ADD Creates an access control profile with 
associated permissions for users and groups to 
the resource specified 

/CHANGE Changes the permissions of users or groups for 
a resource 

/GRANT Adds new user names or group names, as well 
as corresponding permissions, to an existing 
access control profile 

/REVOKE Removes the permissions granted to users or 
groups to use a resource 

/APPLY X Applies the access control profile of the 
specified directory to all the subdirectories 
under it 

/DELETE Removes the access control profile for a 
resource from the access control database 

/TRAIL Turns auditing on or off for a resource 

/FAILURE Audits failed resource access attempts 

/SUCCESS Audits successful resource access attempts 
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Table 8 (Page 2 of 5). New and Altered OS/2 LAN Server 4.0 NET Commands 


























Command Parameter New Function 
NET APP appid X Specifies the unique application ID for the 

application 

/APPDIR X Specifies the directory in which the application 
program resides 

/APPDRIVE xX Specifies the drive letter to be used when the 
connection is made to the /APPDIR directory 
when it is remote 

/COMMAND xX Specifies the program name and any 
parameters to be passed to the program 

/REMARK xX Describes the application 

/WRKDIR xX Specifies the directory to be made current 
when the program runs 

/WRKDRIVE Xx Specifies the drive letter to be used when a 
connection is made when a remote directory is 
specified by /WRKDIR 

/TYPE X Indicates whether the application is a DOS or 
OS/2 application 

/[INTERFACE xX Specifies the user interface that the program 
uses to run - PM, Full Screen, or VIO 

/PROMPT xX Specifies whether the user is to be prompted 
for parameters when the application is started 

/PRIVATE xX Indicates that the application is private to the 
specified user 

/ASSIGN Xx Specifies additional redirections that are 
needed by the application 

/UNASSIGN Xx Deletes redirections associated with an 
application 

/ADD xX Indicates that a new application is to be 
created 

/DEL x Indicates that the application is to be deleted 

/DOMAIN Xx Allows application management on a domain 








other than the logon domain assuming the 
administrator also has the correct privileges on 
that domain 
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Table 8 (Page 3 of 5). New and Altered OS/2 LAN Server 4.0 NET Commands 


Command Parameter 


Function 





NET DASD directory or drive letter 


Specifies a directory on a HPFS386 volume or 
an entire volume 





/ADD 


/ENABLE 


Adds a limit to a directory 
Removes the limit from a directory 


Enables directory limits on a HPFS386 volume 





/INCREMENT 


Specifies the increase beyond the value of the 
/THRESHOLD parameter where mini-thresholds 
are set to further warn of the limit getting 

closer 





/REFRESH 


/DISABLE 


Specifies the limit in multiples of kilobytes to be 
applied to the directory 


Recalculates the disk usage for directories on a 
HPFS386 volume 


Disables directory limit support from a HPFS386 
volume 





/THRESHOLD 


Sets a threshold which is a percentage of the 

directory limit for a directory indicating when to 
issue a warning and a network alert indicating 
that the limit is near 





VALIDATE 


NET TIME servername 
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Displays all the directory limits set in a 
directory tree 


Specifies whether the size of the directory tree 
is to be validated against the new /MAX limit 
immediately 


Identifies the name of the server whose time 
you want to view or synchronize with 





/DOMAIN 


Identifies the domain 





/SET 


Synchronizes the time on this workstation with 
the server or domain time 


Sets the time/date without displaying a prompt 


Does not set the time/date and no prompt is 
displayed 





Sets the date at the specified domain controller 
and synchronizes the clocks of all active 
additional servers with that of the specified 
domain 
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Sets the time at the specified domain controller 
and synchronizes the clocks of all active 
additional servers with that of the specified 
domain 
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Command Parameter New Function 
NET USER username Specifies the name of the account to be added, 

deleted, or modified 

password or * (asterisk) Specifies the password to be assigned to the 
username in the command or displays a prompt 
for the password. 

/ACTIVE Specifies whether this is an active account 

/ADD Adds a user to the domain 

/PRIVILEGE Specifies the user's privilege level 

/COMMENT Provides a descriptive comment about the 
user's account 

/COUNTRYCODE Sets the user's country code 

/EXPIRES Causes the account to expire if a date is set 

/FULLNAME The user's full name (rather than a username) 

/HOMEDIR The path name of the user's home directory 

/SCRIPT X Specify an executable or batch program to be 
run when the user logs on 

/MAXSTORAGE Sets the maximum amount of storage, in 
kilobytes, for a user's home directory, which 
can then be checked by utilities such as 
CHKSTOR. Be aware that this is not the 
enforced limitation provided by the NET DASD 
command for HPFS386 drives. 

/OPERATOR Enables a user to act as an administrator for 








the listed privileges 
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Table 8 (Page 5 of 5). New and Altered OS/2 LAN Server 4.0 NET Commands 


Command 


Parameter 


New 


Function 





NET USER 
(Continued) 


/PASSWORDCHG 


Specifies whether users can change their own 
passwords 





/PASSWORDREQ 


/PASSWORDEXP 


/USERCOMMENT 


Specifies whether a password is required for 
this user account 


Specifies that the user's record is marked for a 
required password change the next time the 
user logs on 


Provides a descriptive comment about the 
user's account 





/DELETE 


Deletes the specified user account from the 
domain 





/TIMES 
/WORKSTATIONS 


/LOGONSERVER 


Specifies the allowed logon hours 


Lists the workstations from which a user can 
log on 


Determines preferred server 





/ASSIGN 


Add logon assignments and public/private 
applications for the user 





/UNASSIGN 


device:alias 


PUBLIC: appid 


Remove logon assignments and public/private 
applications for the user 


When used with the /ASSIGN or /UNASSIGN 
parameter, specifies an item to be added to or 
removed from the specified user's logon 
assignments 


When used with the /ASSIGN or /UNASSIGN 
parameters, specifies that the indicated 
application is to be added to or removed from 
the specified user's application assignments 





PRIVATE: appid 


When used with the /ASSIGN and /UNASSIGN 
parameters, specifies that the indicated 
application is to be added or removed from the 
user's application assignments 





NET USER 
(Continued) 





PUBLIC:ALL 


PRIVATE:ALL 


LOGASN:ALL 





When specified with the /UNASSIGN parameter, 
indicates that all of a user's public application 
assignments are to be deleted 


When specified with the /UNASSIGN parameter, 
indicates that all of a user's private application 
assignments are to be deleted 


When specified with the /UNASSIGN parameter, 
indicates that all of the user's logon 
assignments are to be deleted 





128 Inside OS/2 LAN Server 4.0 





Changed and New DOS LAN Services Commands 


This section contains an alphabetic list of new or altered commands available on 
DOS LAN Services (DLS) requesters. Much more of the function available to 
OS/2 requesters is now available on DLS. For further information, see the 
Commands and Utilities Reference. DLS is also covered in this book in 

Chapter 4, “DOS LAN Services and TCP/IP for DOS.” 


Some commands are still more limited than their OS/2 Requester counterparts, 
but administrative functions can now be managed through the NET ADMIN 
command from a DLS requester. 


Note: The following DOS commands cannot be used with LAN Server network 
devices: 


* ASSIGN 

* BACKUP 

* CHKDSK 
DISKCOMP 
DISKCOPY 
FDISK 

* FORMAT 

* JOIN 
LABEL 
RECOVER 

* RESTORE 

* SUBST 

* SYS 

* VERFIY 


Note: The following commands are no longer available: 


NET - The NET command alone no longer starts the DOS Full Screen 
Interface as this has been replaced with the DOS GUI (NETGUI). 
NET CONTINUE 

NET COPY 

NET MOVE 

NET PAUSE 


The following commands work in the same way in DLS under OS/2 LAN Server 
4.0 as they did in OS/2 LAN Server 3.0 DOS LAN Requester: 


NET LOG 
NET MESSAGE 


Note: The commands apply equally to DLS requesters running DOS only as to 
requesters running DOS and Windows. 


NET ADMIN 


NET ADMIN has the same syntax in DLS as in OS/2 allowing an administrator or 
user with the correct privileges to administer a domain from a DOS workstation. 
The exception is the omission of the /YES parameter. 
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NET ALIAS 


NET CONFIG 


NET DASD 


NET HELP 


NET LOGOFF 


NET LOGON 


NET NAME 


In DLS, NET ALIAS only lists available alias details on the current or a specified 
domain. Use NET ADMIN to do other alias work from a DLS requester. 


NET CONFIG displays your current domain settings as they relate to you. A /YES 
parameter is available to prevent any prompts so the command can be used ina 
batch file. Unlike the OS/2 command there are no options to alter the settings 
through this command. An example of the resultant display follows: 





























Machine ID \\ANNFLMC 
User ID ANNFLMC 
Software version Seal 
Requester version 2.50 
Requester root directory C:\NET 
Requester domain BRISBANE 














The command completed successfully. 


NET DASD displays the limits for a given directory. A /TREE option allows the 
limits for all subdirectories in a tree to be displayed. 


NET HELP is now available in DLS. Help for a command can be gained with 
either the command followed by /? as in NET VIEW /? or by using NET HELP 
command. 





























In addition NET HELP gives help for DLS NET errors. 


In OS/2 LAN Server 4.0 DLS, the NET LOGOFF command has added the /YES 
parameter to allow logging off without prompting. 


In OS/2 LAN Server 4.0 DLS, the NET LOGON command has the enhancement 
that the user name and/or the domain name can be prompted for by using an 
asterisk (*), in addition to allowing a prompt for the password. Also /YES is 
available to avoid other prompts. 


NET NAME with no parameters lists names used by the workstation as 
messaging names. Alternatively, a name can be added or deleted as a 
messaging name for this workstation. 


NET PASSWORD 


As well as adding the /YES parameter to avoid prompts, NET PASSWORD can be 
used to change the password of a specified user in another domain or ona 
specific server. 
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NET PRINT 


NET PRINT has been expanded to work in a similar way to the OS/2 NET PRINT 
command. As well as starting jobs and displaying a remote job status, NET 
PRINT now also maintains remote jobs. Actions allowed are PAUSE (or HOLD) 
and RESUME (or RELEASE) and DELETE. The printer to be maintained can be 
specified by the locally known name (such as LPT1), the machine name on which 
it resides or the full UNC name. The /YES parameter is also added to NET PRINT 
to allow the suppression of a prompt. 


NET SEPARATOR 


NET SHARE 


NET START 


This displays a separator page status or set and change separator pages for 
print jobs. The command allows you to specify the print device for which the 
separator should be altered and the file name containing the separator page. 
Using /D disables the use of a separator page on the specified device. 


This makes server resources available to network users, lists information about 
shared resources currently in effect, and stops sharing resources currently in 
effect. Working in a similar way to the OS/2 NET SHARE command, a netname is 
specified along with a device or files resource, a password for peer resources 
under share-level security, permissions for the resource, a formfeed control for 
print devices and a remark. Deleting a share can apply to named resources or 

all (using an asterisk), and the /YES option is included to avoid prompts. 


NET START is altered to take advantage of DLS memory conservation and 
altered network services. The start options are as follows: 


BASIC - Starts the basic redirector. The basic redirector helps conserve 
memory on your workstation. 


FULL - Starts the full redirector. The full redirector provides support for using 
aliases to identify resources and for using Windows. 


+ MESSENGER - Allows your workstation to receive messages sent across the 
network by other users and servers. 


NETBIND - Binds protocols and network adapter drivers. Allows the binding 
of NETBIOS protocols to adapter drivers without starting the DLS network. 


NETBEUI - Starts the NETBIOS interface without starting the DLS network. 
+ NETPOPUP - Displays messages sent across the network as they arrive. 
PEER - Starts the Peer service. 


REQUESTER - Starts the default redirector, which is the redirector (basic or 
full) you specified during DLS Setup. 


- /LIST - Displays a list of the DLS components that have been started. 


* /YES - Carries out the NET START command without first prompting you to 
provide information or confirm actions. 
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NET STOP 


NET TIME 


NET USE 


NET VER 


NET VIEW 


NET WHO 


This has the same service options as NET START for DLS, allowing each service 
to be stopped and unloaded from memory. 


Note: Windows should be exited before the NET STOP command is used. 


NET TIME checks the time on or synchronizes your workstation's clock with the 
clock on an OS/2 LAN Server time server (that is a server with the TIMESOURCE 
service running). Unlike the OS/2 requester version of this command the domain 
time is not set. 


NET USE is similar to the OS/2 LAN Server 3.0 DLR usage but has been 
extended to allow persistent connections. These are a form of logon assignment 
that will be remade the next time the same user logs on. Also added is the 
ability to prevent the password used being saved locally. See Chapter 4, “DOS 
LAN Services and TCP/IP for DOS” on page 65 and the table in the 
“NETWORK.INI Network Parameters” on page 84 section for further details of 
these facilities. The new parameters are: 


- /PERSISTENT - Specifies which connections are to be restored every time 
this user logs on to DLS. 


* /SAVEPW:NO - Specifies that the password you enter should not be saved in 
your password list file. 


This new command quickly shows the version number of the DLS redirector. This 
can be useful for problem determination. 


The NET VIEW command displays a list of computers that share resources or a 
list of shared resources on a specific computer. NET VIEW can be used as in 
OS/2 Requester with a \\servername and also with a domain name using the 
/DOMAIN parameter. A /YES option is provided to prevent a prompt from 
displaying. 


NET WHO has been expanded in DLS and now lists information about users who 
are logged on in a specified domain or who have connections to a specified 
server or peer server. NET WHO can also be used with a specific user name to 
display more information about that user. 
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Introduction to OS/2 LAN Server 4.0 APIs 


OS/2 LAN Server provides a rich set of application programming interfaces 
(APIs), where each API provides a particular function upon request from an 
application. By calling upon a combination of APIs, your application can use 
nearly all of the OS/2 operating system and LAN Server functions, from file reads 
and writes through interprocess communication (IPC) with other applications. In 
addition, your application can take full advantage of true multitasking and can be 
integrated fully into the OS/2 Desktop. 


Most LAN Server API calls can be issued either locally (to an API on the same 
workstation where the application resides) or remotely (to another workstation 
running the OS/2 LAN Server API code). Hence, your application can use local 
functions as well as LAN-wide functions. 


Programmable functions include those for LAN Server itself, OS/2 LAN 
Requester, and DOS LAN Services (DLS). These functions are accessible to OS/2 
or DLS applications, although DOS has some limitations. 


Note: This section serves only as an introduction to the new function provided 
by these APIs. Refer to the Programming Guide and Reference for additional 
information including new structures, examples and so on. 


Summary of New OS/2 LAN Server 4.0 APIs 


The LAN Server APIs have been enhanced to provide better 32-bit support and to 
extend the function. In addition, instead of simply shipping the headers and 
libraries, OS/2 LAN Server 4.0 includes these plus the softcopy Programming 
Guide and Reference and sample programs. The Programming Guide is installed 
if you perform either the Softcopy Publications installation or LAN Server 
Development Toolkit installation. 


See the Programming Guide for a full description of the available APIs listed by 
programming topics. This section provides some detail for the most significant 
new functions made available to the LAN Server programmer. 


32-Bit Application Enhancement 
In OS/2 LAN Server 3.0 the API design is 32-bit enabled, but is not really 32-bit. It 
depends on the use of the C Set/2 compiler to generate a mixed-model program 
with proper thunking of selector:offset (16:16) pointers for 32-bit use. This makes 
32-bit programs unnecessarily complex and creates an artificial dependency on 
one compiler. 


Note: Thunking is the process of a 32-bit application calling a 16-bit function or 
routine. 


The APIs in OS/2 LAN Server 4.0 provide a set of interfaces for pure 32-bit 
programs. These hide the thunking to any remaining 16-bit APIs allowing a 
gradual change of the LAN Server API code to 32-bit worker routines without 
forcing 32-bit applications to change. 


The new APIs have slightly different interfaces from the 16-bit APIs, partly in 


anticipation that LAN Server will become fully 32-bit in later releases. They can 
be summarized in a few rules: 
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1. Parameters 


+ The number of parameters is the same in both versions. 


Because applications must be compiled with the compiler option that 
defaults char to unsigned char anyway, all variables declared char 
become unsigned char. 


* All short integers, whether signed or unsigned, become unsigned long 


integers in the 32-bit version. This includes reserved parameters. 


* All pointers to char become pointers to unsigned char. 


* All pointers to short integers, signed or unsigned, become pointers to 


unsigned long integers in the 32-bit version. This includes reserved 
parameters. 


2. Data structures 


Except that all references to char become unsigned char, all data 
structures remain as they are, including their alignment. Some 4-byte 
elements may be aligned on 16-bit (WORD) boundaries rather than 32-bit 
(DWORD) boundaries. This is a compromise between speed of execution 
of the API code and application code. 


3. Names 


* The names of the APIs are changed from 16-bit DosXXX to 32-bit 


Dos32XXX and 16-bit NetXXX to 32-bit Net32XXX. The NetBIOS APIs are 
NetBiosXXX for 16-bit, NetBios832XXX for 32-bit. The UPMXXX APIs 
become U32XXX. See “32-Bit Service APIs” on page 135 for the format of 
Service API names. 


- The names of the data structures remain unchanged. 


The last item has an important implication: For a given data structure, you must 
not mix pure 16-bit and 32-bit code. You can, however, successfully write 
programs that use the mixed model (INCL_32 defined) in one file and pure 32-bit 
code (PURE_32 defined) in another. In any case, you must choose only one type: 
pure 16-bit, mixed, or pure 32-bit, for each program file. 


Note: Not all 16-bit APIs have 32-bit entry points. For example, because 16- and 
32-bit file handles are incompatible, there are no Net82Handle APIs. In addition, 
all the APIs in these categories have no thunked counterparts:. 


Named Pipe 


« Print Destination 
« Print Job 


¢ Print Queue 


Spooler 


New 16-bit APIs, such as NetDASD and NeiRIPL, also have thunked 32-bit entry 


points 
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32-Bit Service APIs 


In OS/2 LAN Server 3.0, software applications communicate with network 
services through the use of service APIs. These fully 16-bit APIs allow 
applications to control the operation of network services. For example, they may 
stop a service, or query it for current status. 


The interface between applications and services is built using the 16-bit signal 
facility of OS/2. This facility requires a service to register a 16-bit signal handler 
for communication purposes. In particular, the handler must respond to the 
PROCESS_FLAG_A signal. 


It is possible to write a 32-bit service that uses 16-bit signalling, but at least 
some part of it must contain mixed-model code to use the 16-bit mechanism. 
There is a human-observable delay in sending and processing a signal in this 
manner, probably degrading performance and possibly introducing timing 
problems. In addition, 16-bit signal handlers are given last priority in the new 
OS/2 signaling scheme, potentially allowing some signals to be intercepted by 
32-bit exception handlers and not passed on. 


The aim, therefore, for OS/2 LAN Server 4.0 was to make the Service APIs fully 
32-bit, including the use of 32-bit semaphores for service control. (OS/2's 

exception mechanism has no equivalent of the 16-bit signalling procedure now in 
use). For backwards compatibility, the code must use signals for 16-bit services. 


These calls conform to the conventions stated in “32-Bit Application 
Enhancement” on page 133. 
The list of 32-bit APIs follows: 
Net32ServiceControl - Allow an application to operate on a service. 
Net32ServiceEnum - Allow an application to enumerate all services. 


Net32ServiceGetlnfo - Allow an application to retrieve information about a 
service. 


Net32Servicelnstall - Allow an application to install a service. 


The Access Control Apply Function 
In previous versions of OS/2 LAN Server, the Apply function was available only 
from the full-screen interface (FSI). This function propogates access control lists 
from a specified root directory to all the sub-directories and files under the root. 
The FSI used a private remoting mechanism (logical server) to accomplish this. 


Since the FSI has been removed in LS 4.0, a new API is required to provide the 
Apply function for GUI and command-line interface. 
The new OS/2 LAN Server 4.0 API is: 


NetAccessApply - This applies the access control lists (ACLs) associated 
with a specified directory path to all the subdirectories and files below the 
path. 
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RIPL Management 


The FSI used various executables such as RMM1.EXE to perform RIPL 
workstation management operations. These have now been broken out from this 
executable and are available as the following APIs: 


NetCreateRIPLMachine or Net82CreateRIPLMachine - Create a RIPL client 
from a new or from an existing model. 


NetDeleteRIPLMachine or Net832DeleteRIPLMachine- Delete an existing RIPL 
client. 


NetGetRIPLMachinelnfo or Net32GetRIPLMachinelnfo - Get configuration of 
an existing RIPL client. 


NetSetRIPLMachinelnfo or Net32SetRIPLMachinelnfo - Set configuration of an 
existing RIPL client. 


NetEnumRIPL or Net82EnumRIPL - List RIPL clients defined in the DCDB.M. 


HPFS386 Information Structures 


The HPFS386_GetlInfo() API now exports two additional levels of information via 
HPFS386.DLL, hpfs386_info_1 and hpfs386_info_2. 


Level 1 exports drive-specific information. Level 2 exports system-wide 
information; it is equivalent to the CACHE386 /STATS command. 





The header file, HPFS386.H, describes the structure used for each level. 


HPFS386 Directory Limits DosQSInfo Effect 
The DIR API, DosQFSInfo, is now subject to directory limits. If the command is 
performed against a directory that is subject to directory limits, the bytes free 
value is a function of the limits themselves; it is not the amount of free space on 
the drive. If the directory is not subject to directory limits, the DIR command 
returns the amount of free space on the drive. 


See “General Considerations” on page 114 for further details. 
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The current NetBIOS can support up to 255 sessions per workstation. This is 
because the NCB session number and session number field in the NetBIOS 
protocol frame is a one-byte field. To support more than 254 sessions on a 
single adapter, the API must be changed. Since LAN Server 3.0, you can extend 
the number of sessions by using multiple adapters, which requires no change to 
the APIs. The multiple adapter support allows each adapter to be either 
connected to the same LAN or to different LANs. If they are connected to 
different LANs, the LANs can be bridged. 


To support multiple adapters on the same machine connecting to the same LAN 
segment, a design change was necessary so that each adapter could initialize 
without a NetBIOS naming conflict. In the older design, only one adapter per 
machine could be associated with the machine ID, which is the NetBIOS name 
that is broadcast to the network when the adapter initializes. In the design since 
LAN Server 3.0, NetBIOS checks to see if the duplicate name is coming from an 
adapter on the same machine; if so, the adapter associated with that duplicate 
machine ID is allowed to initialize. The process works as follows: 


1. The ADD.NAME frame handling recognizes when an ADD.NAME.QUERY 
frame arrives from another adapter in the same machine. 


2. The ADD.NAME.RESPONSE frame notifies the sender if there is a duplicate 
NetBIOS name. It cannot be sent if it comes from the same machine. 


3. The LISTEN allows only one adapter to respond to any particular incoming 
call. NetBIOS decides which adapter is to see the incoming call. 


Figure 81 on page 138 illustrates this process. 
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Figure 81. NetBIOS Implementation for More Than 254 Sessions 





Considerations When Using Multiple Adapters 


The following are some points you should consider when using multiple adapters 
in your server. 


Limited Load Balancing 
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When more than two adapters are used in a server on the same LAN, the 
NetBIOS session is established on each adapter in an orderly fashion. For 
instance, in the case of a server with two adapters, Adapter 0 responds to the 
first incoming call, which is a NameQuery frame. A session is established on 
Adapter 0. The next NAME.QUERY is processed by Adapter 1 and a session is 
established on Adapter 1. The third session is held on Adapter 0, and so on. 

This ordering is continued even after some sessions on one adapter are 

dropped. That is, if each adapter has 100 sessions and 50 sessions on Adapter 0 
are dropped, 50 new incoming calls to this server are not held on Adapter 0. In 
this event, 25 sessions are held on Adapter O and 25 sessions on Adapter 1. This 
means the number of sessions on each adapter are not always balanced. The 
following figure shows this environment. 
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Figure 82. Session Allocation in Same LAN Segment 


This simple round-robin mechanism is not used if a bridge exists between two 


LAN adapters. Instead, first-come-first-serve logic is used. This condition is 
detected during the server initialization. The NAME.QUERY frame from 


Requester A will arrive on the LAN Adapter 0 faster than Adapter 1, normally. If 


a LAN segment ring 0 has 100 requesters and ring 1 has 10 requesters, Adapter 


0 will have a maximum of 100 users and Adapter 1 will have a maximum of 10 
users. There is no load balancing function. The following figure shows you this 


environment. 
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Figure 83. Session Allocation in Bridged LAN Segment 


Startup Performance Degradation 


Using multiple adapters causes the starting time and logon times to take longer. 
This is because the LAN Server and requester need to verify that the NetBIOS 
name is not duplicated on the network. This is done by the ADD.NAME.QUERY 
frame, which is sent out every 0.5 seconds. This is repeated six times if the 
default value is used. The ADD.NAME.QUERY frame is serialized for each 
adapter. This means it will take at least n adapters n X 6 X 0.5 seconds to start a 
server/requester and log on. 





Installation of Eight Adapters for OS/2 LAN Server 4.0 
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This section describes how to configure eight adapters for OS/2 LAN Server 4.0, 
which, in theory, would allow for 2000 users. Be aware that OS/2 LAN Server 4.0 
formally supports up to 1000 users. However, a server with eight adapters 
increases the overall performance and also the load balancing. With the IBM 
Dual LANStreamer MC 32 Adapter, which provides two ports, you can now use 
just four physical adapters in your machine to configure/use eight adapters. 
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-— Requester Buffers 


In OS/2 LAN Server 4.0, the maximum number of requester buffers (numreqbuf 
parameter in IBMLAN.INI) is 2000. Since it is best to allocate approximately 

two requester buffers per user, this makes the 1000-user limit a more 

practical limit than in the past, when the recommended maximum number of 
requester buffers was only 300. 











Note: With eight adapters, the IBM OS/2 LAN Server Ultimedia can theoretically 
service up to 80 clients. In this configuration, you could have four FAST/WIDE 
SCSI-2 adapters (each supporting up to 20 users) and four IBM Dual 
LANStreamer MC 32 Adapters. We did not test this configuration. 


The following steps show you how to configure a OS/2 LAN Server 4.0 for eight 
adapters (four IBM Dual LANStreamer MC 32 Adapters) with IEEE 802.2 and 
NetBIOS: 


1. In the MPTS LAPS configuration, add the IBM Streamer Family Adapter 
(IBMMPC.OS2) driver eight times. For each driver, add the IEEE 802.2 and 
NetBIOS protocols. 







elect a network adapter and then select 
Network Adapters 


protocols to go with it. 
Protocols: 












IBM IEEE 802.2 


iM OS/2 NETBIOS 


IBM Netware Requester Suppi4 


BM PCMCIA Token-Ring Network Adapter 
BM PS/2 Adapter for Ethernet Networks | 
BM SMP Token-Ring Network Adapter 

AA EO EE ILL 
Ue IBM OS/2 NETBIOS OVER TCFy 
ZL LT) 


Teena anne hea nega naga neta naa 


















s 






ss 
















\ 






urrent Configuration Sm mm nm nm nn mn Select OK when 


To edit driver parameters, select an item below and complete. 
then select Edit. 







0 - IBM IEEE 802.2 
0 - IBM OS/2 NETBIOS 
“pee tit “y 
ser aS 


y 















i 


teaiel 





Figure 84. Configuring LAPS to Support Eight Adapters 


2. Edit the NetBIOS protocol as shown in Figure 85 on page 142. Enter the 
values for Maximum sessions, Maximum commands, and Maximum names. 
Enter no in the field for Enable NetBIOS application support. 


3. Press OK. 
4. Exit MPTS. 
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Enable NetBIOS application support 
«Network adapter address 

Type of Ethernet driver support 
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NETBIOS trace level 


Maximum sessions 
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Window errors 
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Figure 85. Editing the NetBIOS Protocol Parameters 


5. Edit the CONFIG.SYS file to manually add the four special device statements 
as shown in Figure 86. 


FILES=20 

DEVICE=C : \IBMCOM\PROTOCOL\LANPDD.OS2 
DEVICE=C : \IBMCOM\PROTOCOL\LANVDD.OS2 
DEVICE=C: \IBMCOM\MACS\DUALSTRM.OS2 /S:2 
DEVICE=C: \IBMCOM\MACS\DUALSTRM.OS2 /S:3 
DEVICE=C: \IBMCOM\MACS\DUALSTRM.OS2 /S:4 
DEVICE=C: \IBMCOM\MACS\DUALSTRM.OS2 /S:6 
DEVICE=C: \IBMCOM\LANMSGDD.OS2 /1:C:\IBMCOM 
DEVICE=C: \IBMCOM\PROTMAN.OS2 /I:C:\IBMCOM 






























































Figure 86. CONFIG.SYS - Adding Four IBM Dual LAN Streamer MC 32 Adapters 
The DUALSTRM.OS2 device driver is copied to the d: IBMCOM MACS 
directory. 


If you don't have these statements in CONFIG.SYS, you get the error 
message, LTC0010, which tells you that all IBM Streamer Family Adapters 
must be set to the same interrupt level. 


Note: The /S:x parameter specifies the slot number in which the adapter is 
inserted. 
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Figure 87 on page 143 shows the PROTOCOL.INI file configured for eight 
adapters and two protocols (IEEE 802.2 and NetBIOS). 


[PROT_MAN] 





DRIVERNAME = PROTMANS 








[IBMLXCFG] 


LANDD_nif = LANDD.NIF 
NETBEUI_nif = NETBEUI.NIF 
IBMMPC_nif = IBMMPC.nif 
IBMMPC_nif2 = IBMMPC.nif 
IBMMPC_nif3 = IBMMPC.nif 
IBMMPC_nif4 = IBMMPC.nif 
IBMMPC_nif5 = IBMMPC.nif 
IBMMPC_nif6 = IBMMPC.nif 
IBMMPC_nif7 = IBMMPC.nif 
IBMMPC_nif8 = IBMMPC.nif 

















[LANDD_nif] 


DriverName = LANDDS 


Bindings = IBMMPC_nif, IBMMPC_nif2,IBMMPC_nif3,IBMMPC_nif4,IBMMPC_nif5,IBMMHC_nif6, 


IBMMPC_nif7,IBMMPC_nif8 
ETHERAND TYPE = "I","I","I","r", "D9 "yp", ep" wpe 
SYSTEM_KEY = 0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0 














OPEN_OPTIONS = 0x2000,0x2000,0x2000,0x2000,0x2000,0x2000,0x2000,0x2000 





TRACE = 0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0 
LINKS = 8,8,8,8,8,8,8,8 

MAX_SAPS = 3,3,3,3,3,3,3,3 

MAX_G_SAPS = 0,0,0,0,0,0,0,0 

USERS = 3,3,3,3,3,3,3,3 

TI_TICK_G1 = 255,255,255,255,255, 255,255,255 
T1 TICK GE = 15,15)15,15,15,15)15,15 
T2TLCK-Gl+=::3 3,3 ,3,3;3;,3;3 

TI_ TICK :G2.=..255,255,.255,255,255,255,255,255 
T1 TICK G2 = 25,25,25,25, 25,25) 25525 
T2_TICK_G2 = 10,10,10,10,10,10,10,10 
IPACKETS = 250,250,250,250,250,250,250,250 
UIPACKETS = 100,100,100,100,100,100,100,100 
MAXTRANSMITS = 6,6,6,6,6,6,6,6 

MINTRANSMITS = 2,2,2,2,2,2,2,2 

TCBS = 64,64,64,64,64,64,64, 64 

GDTS = 30,30,30,30,30,30,30,30 

ELEMENTS = 800,800, 800,800,800, 800,800,800 





























[NETBEUI_nif] 


DriverName = netbeuiS$ 


Bindings = IBMMPC_nif, IBMMPC_nif2,IBMMPC_nif3,IBMMPC_nif4, IBMMPC_nif5,IBMMHC_nif6, 


IBMMPC_nif7,IBMMPC_nif8 
ETHERAND_TYPE = "I" 
USEADDRREV = "YES" 
OS2TRACEMASK = 0x0 
SESSIONS = 254 

NCBS = 254 

NAMES = 16 

SELECTORS = 15 
































Figure 87 (Part 1 of 4). PROTOCOL.INI for Eight Adapters 
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USEMAXDATAGRAM = "NO" 
ADAPTRATE = 1000 
WINDOWERRORS = 0 
MAXDATARCV = 4168 

TI = 30000 

T1 = 1000 











T2 = 200 
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PIPELINE = 5 

MAXTRANSMITS = 6 
MINTRANSMITS 
DLCRETRIES = 
FCPRIORITY 
NETFLAGS = 























0 
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[IBMMPC_nif] 


DriverName = IBMMPCS 
MaxTransmits = 31 
MaxTxFrameSize = 18000 
MinRcvBuffs = 20 
SizWorkBuf = 2048 
MulticastNum = 16 
EnableTxEofInt = "YES" 
Enet20UTP = "NO" 
EnableHiPriTx = "NO" 
HiPriTxAccess = 5 
HiPriTxThresh 4 

















[IBMMPC_nif2] 


DriverName = IBMMPCS 











MaxTransmits = 31 
MaxTxFrameSize = 18000 
MinRcvBuffs = 20 
SizWorkBuf = 2048 
MulticastNum = 16 
EnableTxEofInt = "YES" 
Enet20UTP = "NO" 
EnableHiPriTx = "NO" 
HiPriTxAccess = 5 
HiPriTxThresh = 4 








[IBMMPC_nif3] 


DriverName = IBMMPCS 
MaxTransmits = 31 








Figure 87 (Part 2 of 4). PROTOCOL.INI for Eight Adapters 
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MaxTxFrameSize = 18000 
MinRcvBuffs = 20 
SizWorkBuf = 2048 
MulticastNum = 16 
EnableTxEofInt = "YES" 
Enet20UTP = "NO" 
EnableHiPriTx = "NO" 
HiPriTxAccess = 5 
HiPriTxThresh 4 














[IBMMPC_nif4] 


DriverName = IBMMPCS 
MaxTransmits = 31 
MaxTxFrameSize = 18000 
MinRcvBuffs = 20 
SizWorkBuf = 2048 
MulticastNum = 16 
EnableTxEofInt = "YES" 
Enet20UTP = "NO" 
EnableHiPriTx = "NO" 
HiPriTxAccess = 5 
HiPriTxThresh 4 

















[IBMMPC_nif5] 


DriverName = IBMMPCS 
MaxTransmits = 31 
MaxTxFrameSize = 18000 
MinRcvBuffs = 20 
SizWorkBuf = 2048 
MulticastNum = 16 
EnableTxEofInt = "YES" 
Enet20UTP = "NO" 
EnableHiPriTx = "NO" 
HiPriTxAccess = 5 
HiPriTxThresh 4 

















[IBMMPC_nif6] 


DriverName = IBMMPCS 
MaxTransmits = 31 
MaxTxFrameSize = 18000 
MinRcvBuffs = 20 
SizWorkBuf = 2048 
MulticastNum = 16 
EnableTxEofInt = "YES" 
Enet20UTP = "NO" 
EnableHiPriTx = "NO" 
HiPriTxAccess = 5 
HiPriTxThresh 4 

















[IBMMPC_nif7] 


DriverName = IBMMPCS 
MaxTransmits = 31 





Figure 87 (Part 3 of 4). PROTOCOL.INI for Eight Adapters 
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MaxTxFrameSize = 18000 
MinRcvBuffs = 20 
SizWorkBuf = 2048 
MulticastNum = 16 
EnableTxEofInt = "YES" 
Enet20UTP = "NO" 
EnableHiPriTx 
HiPriTxAccess 
HiPriTxThresh 








"NO" 
5 
4 








[IBMMPC_nif8] 


DriverName = IBMMPCS 
MaxTransmits = 31 
MaxTxFrameSize = 18000 
MinRcvBuffs = 20 
SizWorkBuf = 2048 
MulticastNum = 16 
EnableTxEofInt = "YES" 
Enet20UTP = "NO" 
EnableHiPriTx 
HiPriTxAccess 
HiPriTxThresh 











"NO" 
5 
4 











Figure 87 (Part 4 of 4). PROTOCOL.INI for Eight Adapters 


6. Edit the IBMLAN.INI as shown in Figure 88 on page 147. You need to do the 
following: 


* Add the new net2 through net8 statements into the [networks] section, for 
example: 





netx = NETBEUIS,y,LM10,250,250,15 

















where x is a network number associated with the adapter, and y 
indicates the adapter number (starting from 0 for the first adapter). 


* Add net2 through net 8 to the wrknets and srvnets statements. 


* We also made changes to the following Server parameters to allow for 
up to 1000 users. This is not necessary for setting up eight adapters. 


- maxusers = 1000 
- maxconnections = 1010 
- numreqbuf = 2000 
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; OS/2 LAN Server Advanced initialization file 


[networks ] 
neti = NETBEUIS, 0 ,LM10,250,250,15 
net2 = NETBEUIS, 1 ,LM10,250,250,15 
net3 = NETBEUIS, 2 ,LM10,250,250,15 
net4 = NETBEUIS, 3 ,LM10,250,250,15 
net5 = NETBEUIS, 4 ,LM10,250,250,15 
net6 = NETBEUIS, 5 ,LM10,250,250,15 
net7 = NETBEUIS, 6 ,LM10,250,250,15 
net8 = NETBEUIS, 7 ,LM10,250,250,15 


; This information is read by the redirector at device initialization time. 


[requester] 





COMPUTERNAME = ANYSRV02 
DOMAIN = ANYDOM02 











wrknets = NET1,NET2,NET3,NET4,NET5,NET6,NET7,NET8 


[server] 


alertnames = 

auditing = resource 

autodisconnect = 120 

maxusers = 1000 <- This is for 1000 users 

not required for 8 adapters) 


maxconnections = 1010 <- This is for 1000 users 
not required for 8 adapters) 


numreqbuf = 2000 <- This is for 1000 users 
not required for 8 adapters) 














srvnets = NET1,NET2,NET3,NET4,NET5,NET6,NET7,NET8 





Figure 88. IBMLAN.INI for Eight Adapters 


After configuring for the eight adapters, you can now use the LSTUNE tool 
included with OS/2 LAN Server 4.0 to tune your configuration files. 


After you have restarted the workstation, you should verify that all drivers have 
loaded successfully and that IEEE 802.2 and the NetBIOS protocol are active. You 
can check the LANTRAN.LOG file for this information. 


Figure 89 on page 148 shows our LANTRAN.LOG file. You can see that all eight 
adapters are bound successfully. 
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IBM OS/2 
Slot 2A: 
IBM LANDD 
Slot 2A: 
Adapter 0 
Adapter 0 
IBM LANDD 
Slot 2B: 
IBM LANDD 
Slot 2B: 
Adapter 1 
Adapter 1 
IBM LANDD 
Slot 3A: 
IBM LANDD 
Slot 3A: 
Adapter 2 
Adapter 2 
IBM LANDD 
Slot 3B: 
IBM LANDD 
Slot. 3B: 
Adapter 3 
Adapter 3 





























IBM OS/2 LANMSGDD 08/14/94" 2.01 is loaded and operational. 
IBM OS/2 LAN Protocol Manager 
IBM - OS/2 Socket/MPTS Common Transport Semantics 
IBM OS/2 NETBEUI 2.20.1 

NETBEUL: Using a 32-bit data segment. 














IBM Streamer Family adap 


Installing NETWKSTA.200 Version 4.0. IBM LAN Redirector (Aug 07, 1994) 

IBM OS/2 LANDD 08/14/94” 2.20.12 

IBM OS/2 LANDLLDD 2.01 

IBM OS/2 LANDLLDD is loaded and operational. 

IBM Streamer Family adapter NDIS device driver Version 3.00.00 

Initialization proceeding for section IBMMPC_NIF in PROTOCOL. INI 
Initialization proceeding for section IBMMPC_NIF2 in PROTOCOL. INI 
Initialization proceeding for section IBMMPC_NIF3 in PROTOCOL. INI 
Initialization proceeding for section IBMMPC_NIF4 in PROTOCOL. INI 
Initialization proceeding for section IBMMPC_NIF5 in PROTOCOL. INI 
Initialization proceeding for section IBMMPC_NIF6 in PROTOCOL. INI 
Initialization proceeding for section IBMMPC_NIF7 in PROTOCOL. INI 
Initialization proceeding for section IBMMPC_NIF8 in PROTOCOL. INI 

IBM OS/2 NETBIOS 4.0 

Adapter 0 has 4 NCBs, 4 sessions, and 1 names available to NETBIOS applications}. 
Adapter 1 has 4 NCBs, 4 sessions, and 1 names available to NETBIOS applications}. 
Adapter 2 has 4 NCBs, 4 sessions, and 1 names available to NETBIOS applications}. 
Adapter 3 has 4 NCBs, 4 sessions, and 1 names available to NETBIOS applications}. 
Adapter 4 has 4 NCBs, 4 sessions, and 1 names available to NETBIOS applications}. 
Adapter 5 has 4 NCBs, 4 sessions, and 1 names available to NETBIOS applications}. 
Adapter 6 has 4 NCBs, 4 sessions, and 1 names available to NETBIOS applications}. 
Adapter 7 has 4 NCBs, 4 sessions, and 1 names available to NETBIOS applications}. 
NETBIOS 4.0 is loaded and operational. 


IBM LANVDD is loaded and operational. 
LAN Netbind 


ter universal address is 08005a6c021b 


is accessing IBM 802.5 LAN Interface. 


IBM Streamer Family adap 
was initialized and open 


is using node address 08005A6C021B. 


was successfully bound t 
IBM Streamer Family adap 


ter opened for: 
ed successfully. 


Token Ring, 4 Mbps. 





o MAC: IBMMPC_nif->VECTOR. 
ter universal address is 08005a6c021c 


is accessing IBM 802.5 LAN Interface. 


IBM Streamer Family adap 
was initialized and open 


is using node address 08005A6C021C. 


was successfully bound t 
IBM Streamer Family adap 


is accessing IBM 802.5 LAN Interface. 


IBM Streamer Family adap 
was initialized and open 


is using node address 08005A6C020B. 


was successfully bound t 
IBM Streamer Family adap 


is accessing IBM 802.5 LAN Interface. 





IBM Streamer Family adap 
was initialized and open 


is using node address 08005A6C020C. 
IBM LANDD was successfully bound to MAC: 


ter opened for: 
ed successfully. 


Token Ring, 4 Mbps. 





o MAC: IBMMPC_nif2->VECTOR. 
ter universal address is 08005a6c020b 


ter opened for: 
ed successfully. 


Token Ring, 4 Mbps. 





o MAC: IBMMPC_nif3->VECTOR. 
ter universal address is 08005a6c020c 





ter opened for: 
ed successfully. 


Token Ring, 4 Mbps. 








IBMMPC_nif4->VECTOR. 





Figure 89 (Part 1 of 2). LANTRAN.LOG File for Eight Adapters 
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Slot 4A: 
IBM LAND. 
Slot 4A: 
Adapter 
Adapter 
IBM LAND 
Slot 4B: 
IBM LAND. 
Slot 4B: 
Adapter 
Adapter 
IBM LAND. 
Slot 6A: 
IBM LAND 
Slot 6A: 
Adapter 
Adapter 
Adapter 
Adapter 
Adapter 
Adapter 
Adapter 
Adapter 
Adapter 














1s) 





D 


SAYDUPWNR OD 


IBM Streamer Family adap 


is 


accessing IBM 802.5 L 


IBM Streamer Family adap 
was initialized and opened successfully. 


is 


was successfully bound t 


using node address 08 


IBM Streamer Family adap 


is 


accessing IBM 802.5 LAN Interface. 


IBM Streamer Family adap 
was initialized and opened successfully. 


is 


was successfully bound t 


using node address 08 


IBM Streamer Family adap 


is 


accessing IBM 802.5 LAN Interface. 





IBM Streamer Family adap 
was initialized and opened successfully. 


is 
is 
is 
is 
is 
is 
is 
is 


using node address 08 
using node address 08 
using node address 08 
using node address 08 
using node address 08 
using node address 08 
using node address 08 
using node address 08 


ter universal address is 08005a6c020f 
AN Interface. 
ter opened for: Token Ring, 4 Mbps. 


OO5A6CO020F. 
o MAC: IBMMPC_nif5->VECTOR. 
ter universal address is 08005a6c0210 





ter opened for: Token Ring, 4 Mbps. 


005A6C0210. 
o MAC: IBMMPC_nif6->VECTOR. 
ter universal address is 08005a6c0227 











ter opened for: Token Ring, 4 Mbps. 


005A6C021B. 
OO5A6C021C. 
OO5A6CO20B. 
O0O05A6C020C. 
OO5A6CO020F. 
005A6C0210. 
005A6C0227. 
005A6C0228. 





Figure 89 (Part 2 of 2). LANTRAN.LOG File for Eight Adapters 
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Chapter 8. Migration and Coexistence Among LAN Server Versions 


This chapter discusses considerations for migrating from LAN Server 2.0 
Entry/Advanced and LAN Server 3.0 Entry/Advanced to LAN Server 4.0 
Entry/Advanced. Included is information about compatibility among servers and 
requesters, and information about access control list (ACL) utilities for HPFS386. 


Access Control Related Utilities for HPFS386 Servers 


© Copyright IBM Corp. 1995 


This section describes the access control list (ACL) utilities that can be used to: 


Upgrade a LAN Server 2.0 or 3.0 Advanced workstation to a new version of 
OS/2 and LAN Server 4.0 Advanced 


Note: These utilities are not necessary if you are only upgrading your 
version of LAN Server Advanced and not upgrading OS/2. 


Reinstall OS/2 on a LAN Server 4.0 Advanced workstation 
Install a new OS/2 release on a LAN Server 4.0 Advanced workstation 


Install a Corrective Service Diskette (CSD) on a LAN Server 4.0 Advanced 
workstation. 


OS/2 uses its own file system (OS/2 HPFS) to read and write files during 
installation. Files and directories protected by HPFS386 access control profiles 
cannot be accessed by the OS/2 HPFS. To bypass this potential problem and to 
ensure proper migration, LAN Server 4.0 provides two utilities: 


PREPACL 


PREPACL removes ACLS and can restore them after LAN Server 4.0 
Advanced is installed. This utility is only necessary if you have ACLs for C: , 
C: OS2, or files/directories under C: OS2 (if you have installed local security, 
for example). The removal process should be done very carefully to ensure 
that you do not lose the ACLs. 


PREPACL must be run twice: once to remove the ACLs and again to restore 
them after LAN Server 4.0 Advanced is installed. This procedure may take a 
long time if there are many ACLs on the drives. 


* THIN386 


The THIN386 utility creates a mini HPFS386 so that OS/2 can access files 
protected by 386 HPFS ACLs during LAN Server 4.0 Advanced installation. 
With the THIN386 utility, you don't have to remove the ACLs from all drives. 
However, if C: or C: OS2 directories are protected by access control 
profiles, the OS/2 installation is not possible. You must remove the ACLs on 
C: or C: OS2 using PREPACL before OS/2 installation. If you have installed 
local security, ACLs are created for these directories during installation 

(since they are part of the PATH environment variable), so you have to 
remove them. 


It is our assumption that ACLs only exist for subdirectories under IBMLAN and 
directories/files for the user drives. In this case, you normally don't have to use 
the PREPACL utility. However, if you are not sure if there are ACLs for other 
directories/files, we recommend that you use the PREPACL before the migration 
process. 
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PREPACL Utility 
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PREPACL and THIN386 are on the server #1 diskette and the CD-ROM. 


PREPACL backs up, removes, and later restores all HPFS386 access control 
profiles applied to any subdirectories or files specified as the parameter. Be 
careful, since PREPACL removes the ACL and copies backup information to an 
ASCII file. Careless repeat usage of this utility will overwrite the specified ASCII 
file contents, and the ACL will be completely lost. 


The following example creates the file, ACLSAVE, and removes all of the ACL 
from the drive. Here, it is assumed the HPFS386 system is IPLed from the hard 
disk and not from diskette. 





PREPACL /P /B:C: ACLSAVE /D:C: 

















PREPACL is not intended to be used with CID redirected install. The main 
purpose is for migrating to a new version of OS/2 and to LAN Server 4.0 
Advanced from LAN Server 2.0 or 3.0 Advanced. Any HPFS386 unique ACLs 
should be removed during the migration, unless the THIN386 is installed right 
after OS/2 is installed. 


PREPACL can also be used as a kind of disaster recovery in case of lost ACLs. 
You can prepare an ASCII file which contains all the access control definitions, 
as shown in Figure 90 on page 153. PREPACL is a batch type interface for 
handling HPFS386 ACLs. 


Note: For information on PREPACL syntax, see Appendix A, “Migration and 
Backup Utilities” on page 421. Also, the OS/2 LAN Server 4.0 Network 
Administrator Reference Volume 1: Planning, Installation, and Configuration has 
additional information on PREPACL. 


Inside OS/2 LAN Server 4.0 


THIN386 Utility 








USERS : RWCXDAP 
MLAN \ BOOK" 
SERS:R 

ESTS:R 


LAN\DCDB" 


LAN\DCDB\APPS" 





LAN\DCDB\ DATA" 








LAN\DCDB\DEVICES" 

















LAN\DCDB\FILES" 





LAN \DCDB\ IMAGES" 








LAN\DCDB\LISTS" 




















"c: \IBMLAN\DCDB\PRINTERS" 
ERS:R 
GUESTS:R 











"c: \IBMLAN\DCDB\USERS\SERVER_B" 
SERVER_B : RWCXDAP 


























"c: \IBMLAN\DCDB\USERS\SERVER_B\BATCH" 
SERVER_B : RWCXDAP 
































Figure 90. PREPACL Output ASCII File Sample 


THIN386 creates a small version of the HPFS386 file system that enables OS/2 to 
access files that have the HPFS386 access control profiles. This utility is required 
when you install a new version of OS/2 and LAN Server 4.0 Advanced on top of 
LAN Server 2.0 or 3.0 Advanced. The OS/2 HPFS file system cannot access 
ACL-protected HPFS386 directories and files. This means, for example, the 
IBMLAN DCDB subdirectory cannot be updated. With the THIN386 utility, 
HPFS386 files are accessible and LAN Server 4.0 Advanced installation can be 
done. 


The THIN386 utility is intended to be used as a temporary file system during a 
migration to LAN Server 4.0. The sample command line for THIN386 is: 


THIN386 /B:C: /T:C: IBM386FS 
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where /B specifies the CONFIG.SYS location, and /T specifies the target path in 
which to install the temporary HPFS386. 





BACKACC and RESTACC 


The NET.ACC file in d: IBMLAN ACCOUNTS contains user and group 
information. It also includes server-specific access control information for File 
Allocation Table (FAT) drives, pipes, printers and serial devices. Server unique 
information is not copied automatically to the other servers in the domain. Also, 
NET.ACC doesn't have access control profiles for the HPFS386, because ACLs 
are in an integral part of the file system. 


BACKACC and RESTACC utilities must be used to back up and restore the 
NET.ACC file and the access control information for HPFS386 drives. If you have 
multiple HPFS drives, you must issue the BACKACC command specifying the 
drive letter for each drive. 


Note: If you are upgrading to LAN Server 4.0 from a previous LAN Server 
version, be sure to use the utilities that come with the LAN Server 4.0 product. 


Migration from LAN Server 2.0/3.0 Entry to 4.0 Entry 


The following steps guide you on how to migrate from LAN Server 2.0 Entry or 
3.0 Entry to LAN Server 4.0 Entry: 


1. Stop all LAN services. 


Ensure all users are logged off and none of the resources on the server are 
being used during the upgrade process. Otherwise, the backup procedure 
does not complete successfully. 


2. Run the BACKACC command for each drive to make a backup copy of NET.ACC, 
NET.AUD and the ACLs. 


BACKACC Example: 


The following example backs up NET.ACC and NET.AUD and replaces the 
target file ACLBAKE.ACL with access control information associated with E: 
and all access control profiles under E: . 


BACKACC E: /S 
3. Install LAN Server 4.0 Entry over LAN Server 2.0 Entry or 3.0 Entry. 





During the installation process, the system tells you that a domain control 
database may exist on the hard disk. 


Select: Do not reinitialize the domain control database 


Migration from LAN Server 2.0/3.0 Entry to 4.0 Advanced 
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The following steps guide you on how to migrate from LAN Server 2.0 Entry or 
3.0 Entry to LAN Server 4.0 Advanced: 


1. Stop all LAN services. 


Ensure all users are logged off and none of the resources on the server are 
being used during the upgrade process. Otherwise, the backup procedure 
does not complete successfully. 


2. Run the BACKACC command for each drive to make a backup copy of NET.ACC, 
NET.AUD and the ACLs. 
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BACKACC Example: 


The following example backs up NET.ACC and NET.AUD and replaces the 
target file ACLBAKE.ACL with access control information associated with E: 
and all access control profiles under E: . 


BACKACC E: /S 
3. Install LAN Server 4.0 Advanced over LAN Server 2.0 Entry or 3.0 Entry. 





During the installation process, the system tells you that a domain control 
database may exist on the hard disk. 


Select: Do not reinitialize the domain control database 


4. Run the RESTACC command for each drive to restore the NET.ACC, NET.AUD 
and the ACLs. 


RESTACC Example: 





The following example restores the access control information stored in the 
ACLBAKE.ACL file. ACLBAKE.ACL is the default file for drive E. 


RESTACC E: /S 


Tr 








5. Run PREPACL again to restore the ACLs if required. 





Migration from LAN Server 2.0/3.0 Advanced to 4.0 Advanced 


In this scenario, HPFS386 already exists on the LAN Server 2.0 Advanced or LAN 
Server 3.0 Advanced server. If you also need to upgrade the version of OS/2 
(not just upgrading to LAN Server 4.0), you may have some additional steps. 
Since OS/2 uses its own HPFS to read and write files during and after the 
installation, it cannot access files and directories that are protected by the 
HPFS386 access control profiles. 


This is only a problem if there are ACLs for C: , C: OS2, or any files/directories 
under C: OS2 that OS/2 needs to access during installation. Ordinarily, you 

would not have ACLs for these directories, but you can check by using either the 
full-screen interface (Definitions-Access Control- Servers) or with the NET ACCESS 
command (use the /TREE option). 


























Note: If you are upgrading from LAN Server 3.0 Advanced and you are using 
local security, you will need to run PREPACL, since ACLs will exist for those 
OS/2 directories. 


If you do have ACLs for these directories, LAN Server 4.0 provides two utilities, 
PREPACL and THIN386, to help the migration. PREPACL and THIN386 have 
different approaches for overcoming the ACL problems. 


PREPACL removes the ACLs from a specified drive and saves the ACLs 
information to an ASCII file. PREPACL also restores the ACLs from the ASCII file 
to the specified drive. If the installation has many drives, PREPACL must be 
executed for each drive. 


On the other hand, the THIN386 approach is to install a mini HPFS386 in the 
maintenance directory so the ACL-protected files and subdirectories can be 
accessed by the OS/2 installation. The THIN386 approach assumes the system 
will boot from the hard disk. With THIN386, you don't have to remove ACLs. 
However, THIN386 also assumes C: has no ACLs. 
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The following steps guide you on how to migrate from LAN Server 2.0 Advanced 
to LAN Server 4.0 Advanced: 


Note: We tested this scenario by creating a LAN Server 3.0 Advanced with 100 
users, 100 aliases, and 10 applications and did not find a problem with the 
migration to LAN Server 4.0 Advanced. 


1. Stop all LAN services. 


Ensure that all users are logged off and that none of the resources on the 
server are being used during the upgrade process. Otherwise, the backup 
procedure does not complete successfully. 


2. Run the BACKACC command for each drive to make a backup copy of NET.ACC, 
NET.AUD and the ACLs. 


BACKACC Example: 


The following example backs up NET.ACC and NET.AUD and replaces the 
target file ACLBAKE.ACL with access control information associated with E: 
and all access control profiles under E: . 


BACKACC E: /S 





3. Run PREPACL from LAN Server 4.0 diskette #1 to remove ACLs on C: drive. 
PREPACL Example: 





The following example removes 386 access control profiles from the file 
system and stores the information to the file ACLDRC. 





PREPACL /P /B:C: ACLDRC /D:C: 
4. Install OS/2. 
5. Install LAN Server 4.0 Advanced over LAN Server 2.0 Advanced. 

















During the installation process, the system tells you that a domain control 
database may exist on the hard disk. 


Select: Do not reinitialize the domain control database 


6. Run the RESTACC command for each drive to restore the NET.ACC, NET.AUD 
and the ACLs. 


RESTACC Example: 





The following example restores the access control information stored in the 
ACLBAKE.ACL file. ACLBAKE.ACL is the default file for drive E. 


RESTACC E: /S: 
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Compatibility Among Servers and Requesters 


This section describes the compatibility among various IBM server and 

requester products on a LAN. Servers with different OS/2 LAN Server packages 
installed can coexist in a single domain. For example, a domain can have an 
OS/2 LAN Server Advanced domain controller and two OS/2 LAN Server Entry 
additional servers. 


OS/2 LAN Server 2.0 and 3.0 servers can coexist with OS/2 LAN Server 4.0 
servers on the same domain (with either as the domain controller). 


Access capabilities of various IBM LAN Requester products to resources on IBM 
LAN Server domains are described in Table 9 on page 158 and Table 10 on 
page 160. The following three areas are covered: 


Logging on to a domain 
+ Administering a domain 
* Accessing external resources across domains 


The IBM LAN Server domains illustrated are: 


PC LAN Program 1.31 (or later) Extended Services (SBCS systems only) 
* OS/2 LAN Server 1.3 
* OS/2 LAN Server 2.0 
* OS/2 LAN Server 3.0 
* OS/2 LAN Server 4.0 


The IBM LAN Requester products addressed are: 


+ PC LAN Program 1.31 (or later) Base Services Requester (also requires IBM 
LAN Support Program) (SBCS systems only) 
PC LAN Program 1.31 (or later) Extended Services Requester (also requires 
IBM LAN Support Program) (SBCS systems only) 

* OS/2 LAN Requester shipped with OS/2 Extended Edition 1.3 

* OS/2 LAN Requester shipped with LAN Server 2.0, 3.0, and 4.0 
DOS LAN Requester shipped with OS/2 LAN Server 1.3 (SBCS systems only), 
2.0, or 3.0 (also requires IBM LAN Support Program) 
LAN Enabler 2.0 (includes OS/2 LAN Requester and DOS LAN Requester) 
DOS LAN Services shipped with IBM OS/2 LAN Server Version 4.0 


Logon and Administrative Capabilities 
Table 9 on page 158 illustrates the logon (L) and administrative (A) capabilities 
of various requester products. 


An SBCS user can use a PC LAN Program 1.31 (or later) Base Services 
requester to log on to a domain controlled by an IBM OS/2 LAN Server 4.0 
server and can access domain resources available to that user ID. However, 
this user is not able to perform any administrative tasks in that domain. 
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Table 9. Logon and Administrative Capabilities 


LAN Requesters 


PCLP 1.31 or later (Base 
Services) running on a DOS 
or an OS/2 workstation 


PCLP 1.31 (or later) (ES) 
running on a DOS or an OS/2 
workstation 


OS/2 LAN Requester (shipped 
with EE 1.3) 


OS/2 LAN Requester (shipped 
with LAN Server 2.0) running 
on OS/2 1.3 or OS/2 2.0 


OS/2 LAN Requester ( 
with LAN Enabler 2.0) 


OS/2 LAN Requester (shipped 
with LAN Server 2.0, 3.0, or 
4.0) running on OS/2 2.0 or 
2.1 or higher 





shipped 


DOS LAN Requester (shipped 
with OS/2 LAN Server 1.3, 2.0, 
or 3.0, or LAN Enabler 2.0) 
running on a DOS or an OS/2 
workstation 


DOS LAN Services (shipped 
with LAN Server 4.0) 


Abbreviations: 


* A= administrative capabilities 


¢ EE = OS/2 Extended Edition 
* ES = Extended Services 

* L = logon capability 

* PCLP = PC LAN Program 

¢ SE = Standard Edition 





PCLP 1.31 
or later 
(ES) 





LAN 
Server 1.3 
(on EE 1.3) 


L, A6 


L, A6 


L, A5,9,10 





LAN Server Domains 


LAN 
Server 2.0 
(on SE 1.31 
or OS/22) 





L, A7 


LA 


L, A5,9,10 


LAN 
Server 3.0 
(on OS/2) 


L4,5 


L, A? 


L, A7.8 


L, A? 





L, A5,9,10 





LAN 
Server 4.0 
(on OS/2) 


L4,5 


L, A7 


L, A7.8 


L, A7.8 


LA 


L, A5,9 


L, A5,9,10 





Notes: 


1. OS/2 Standard Edition 1.3 must be at CSD level XR5050 (or greater). 


. LAN Server 2.0—Advanced runs only on OS/2 Standard Edition 1.3. 


2. 

3. PC LAN Program is available on SBCS systems only. 

4. The network administrator defines a user ID that matches the machine name of the PC LAN Program Base Services 
workstation. When the workstation issues a NET USE command, the machine name is validated against the defined user 


IDs. 


OANDUW 


. Access to serial devices is not supported. 
. LAN Server 1.3 must be at CSD level WR5050 (or greater). 
. Administration of new functions, such as Fault Tolerance, is not supported. 
. LAN Server does not support the remote IPL of OS/2 1.3 requesters. 

. Administrative capabilities are available from the LAN Server APIs. To access the APls, you must load the DOS LAN 


APIs. For detailed information, see the LAN Server Programming Guide and Reference. To load the APls, run the DOS 
LAN client with the /API parameter in the DOSLAN.INI file. 
10. Administration via NET ADMIN supported. 
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Access to External Resources 

Table 10 on page 160 illustrates the access capabilities of various IBM LAN 
Requester products to resources on domains other than the logged-on domain. 
Access to resources across domains is accomplished through cross-domain 
aliases, through the use of appropriate APls, or by using explicit NET SHARE and 
NET USE commands. A cross-domain alias points to a LAN Server resource on 
a server outside the current domain. Once a user's ID and password are 
validated, that user can access resources in another domain, provided the 
network administrator of that domain has shared the resources and granted the 
appropriate access permissions. 


For example, if a user of OS/2 LAN Requester is logged on to an OS/2 LAN 
Server 1.3 domain and requires access to resources in an OS/2 LAN Server 
domain, the following resource definitions must exist: 


The desired resource in the OS/2 LAN Server domain must be defined as 
shared. 
The resource must be defined as an external resource in the OS/2 LAN 
Server 1.3 domain. 

* The user ID and password, if applicable, must be defined in the OS/2 LAN 
Server domain. 


Setting up a guest account is an alternative method of providing access to 


external resources. For more information, see the LAN Server Network 
Administrator Reference Volume 3: Network Administrator Tasks. 
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Table 10. Access to External Resources Across Domains 











External Resource Domain to Be Accessed 
Reiacter Domialiy PCLP1 os/2 Os/2 os/2 os/2 
q 1.31 or LAN LAN LAN LAN 
later Server Server Server Server 
(ES) 1.3 2.02 3.02 4.02 
PCLP1 1.31 or later Not applicable Xx X38 X38 X38 x3 
(Base Services) 
PCLP1 1.31 or later PCLP 1.31 or later Xx X3 X3 X3 X3 
(ES) 
OS/2 LAN Requester OS/2 LAN Server 1.3, x xX x X X 
2.0, 3.0, or 4.0 
DOS LAN Client OS/2 LAN Server 1.3, x Xs x3 X3 x3 
2.0, 3.0, or 4.0 

















Abbreviations: 


+ ES = Extended Services! 
+ PCLP = PC LAN Program! 


Notes: 
X indicates access capability. 


1. Applies to SBCS systems only. 
2. Applies to both LAN Server Entry and LAN Server Advanced 
3. Access to serial devices is not supported. 


Note: A user account which is maintained on a domain that is running LAN 
Server 2.0 or 3.0 cannot have its ability to be deleted/modified after the user 
account is created. If you are using LS 4.0 GUI to update the user account 
information for a domain that is not at the 4.0 level, the Deletable field appears to 
be modified, but the NET.ACC is not updated with the new state. 


An alias, which is maintained for a domain that is running a LAN Server 2.0 or 
3.0, cannot have its server name and path updated after the alias is created. If 
you are using the LAN Server 4.0 GUI to update the alias information for a 
domain that is not at the 4.0 level, the fields appear to be modified, but the 
DCDB is not updated with the new information. 
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Chapter 9. LAN Server 4.0 Interoperability 


In this chapter, we discuss OS/2 LAN Server 4.0 interoperability with other 
products in the marketplace from both the requester and server points of view. 
This shows you different ways to set up your environment with LAN Server and 
other products, allowing you to use different client software to access LAN 
Server. 





Our Test Environment 
Figure 91 shows our test environment. 
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Figure 91. LAN Server Interoperability Test Environment 


We tested to see how the different servers can be accessed from the different 
client types. As you can see in the following table, we concentrated on non-LAN 
Server clients accessing LAN Server 4.0, and LAN Server 4.0 clients accessing 
non-LAN Server servers. Specifically, we wanted to see if and how users can: 


* Log on to the servers 

* Access the servers’ resources, including network applications 
+ Get home directory assignments (if logon is allowed) 

* Get logon scripts (if logon is allowed) 


* Manage the server 
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Table 11 shows our general test results. See “Microsoft Clients Accessing OS/2 
LAN Server 4.0” on page 164 for more detail. 


Table 11. LAN Server 4.0 Interoperability Overview. 


Servers 

Workstations ; Windows for 

Pipes LAN Resieger Windows NT Workgroups NetWare 3.12 NetWare 4.02 

4.0 . Advanced 3.1 3411 

3 
poe EAN All functions Bata L,U U All functions4 All functions4 
Services 4.0 Ss 
OS/2 LAN ! L,U,G,S L,U,G,A ' : 
, df, &: 4. , + , , 4 4 

Requester 4.0 All functions M2 U All functions All functions 


DOS LAN 
Manager 2.2 
workstation 


OS/2 LAN 
Manager 2.2 
workstation 


Windows NT 
3.1 
workstation 


ND 
No 


= 
wo 


Not tested Not tested Not tested Not tested Not tested 


Not tested Not tested Not tested Not tested Not tested 


Not tested All functions Not tested Not tested Not tested 


Windows for 
Workgroups 
3.11 


DOS NetWare 
Requester All functions4 
3.12 & 4.02 


os/2 
NetWare 
Requester 
3.12 & 4.02 


Not tested Not tested All functions® All functions All functions® 


Not tested Not tested Not tested All functions All functions 


Not tested Not tested Not tested All functions All functions 


All functions4 














Legend: 


Logon to the server 

Use the server's resource 
Home directory assigned 
Network application 

Guest account access accepted 
Logon assignments 

Manage server resources 
Logon scripts 


MO2P7QO0UTCr 


1 Group definitions can be managed from GUI; other administrative functions from GUI allow for displaying only. 

2 User and group definitions can be managed only from the GUI (NET ADMIN not supported) 

3 You can manage servers by using the NET ADMIN command 

4 Requires workstation to be running both LAN Server requester and NetWare Requester. 

5 Requires workstation to be running both Windows for Workgroups and NetWare Requester. 

6 All functions allowed by the product architecture (in this case, peer-to-peer functions). 

7 Logon scripts work if you add a script file using the NET USE userid /SCRIPT:script_filename command. 




















The following gives more explanation on the table: 


* L- Logon to the server 
This means that you can log on to the server and be validated. 


* U- Use resource 
This indicates that you can use the server's resource. However, if L is not 
also specified, this means that you are not validated for logon but you can 
use the resource with the NET USE command. 
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H - Home directory assigned 
This indicates that during the logon process, you can receive a home 
directory when there is one assigned for your ID at the server. 


N - Network Application 

This indicates that you can access Public or Private network applications set 
up on LAN Server, if any application is defined. This is a LAN 
Server-specific function, and is available to LAN Server requesters only. 


G - Guest Access 
This indicates that you can access the server's resource using a guest 
account, that is, without logging on to that specific domain or server. 


* A- Logon Assignments 


This indicates that you have all LAN Server logon assignments added to the 
user ID during logon time. Logon assignments are automatically made to 
connect the logged-on user to network resources. These assignments can 
be made for users in the domain from either LAN Server 4.0 GUI or NET 
USER command. After creating an alias to a resource outside of your 
domain, you can also set up this resource as a logon assignment for any 
user in the domain. Also, using the GUI, you can easily assign a resource to 
a group using OS/2's drag and drop function. 


This is in addition to the added function of assigning a Public or Private 
application to a user at logon. 


M - Management 
This indicates that you can do some management of your server. In some 
cases, this is allowed only via the NET ADMIN command. 


S - Logon Scripts 

This indicates that the workstation can interpret the logon scripts, if there are 
any defined on the server. Microsoft LAN Manager uses this mechanism to 
assign resources to users every time they logon to the server. 


LAN Server 4.0 supports logon scripts in addition to the Logon Assignments 
function and logon profiles (PROFILE.CMD and PROFILE.BAT). To use a 
logon script, you must add a script file for the user using the following 
command: 





NET USE userid /SCRIPT:script_filename 














This option is available only from the command line. 


The script file must be located in the path pointed to by the NETLOGON 
resource. The NETLOGON resource is automatically shared (by netname 
only, not by alias) on each server when the Netlogon service starts. By 
default, the Netlogon service starts whenever you start the server, and the 
NETLOGON netname points to IBMLAN REPL IMPORT SCRIPTS. If you 
keep this default, be sure that script files are located in this directory on the 
server. If you wish to change this location, edit the server IBMLAN.INI file, 
and change the scripts= parameter in the [net Logon] section to point to 
another path. 


One reason why you may want to use logon scripts is if you have any 
Microsoft LAN Manager or Windows for Workgroups clients logging on to 
your LAN Server 4.0 domain. As you can see from the previous table, logon 
to a LAN Server 4.0 domain is possible for these users; however, these users 
cannot receive any LAN Server-specific logon assignments since those are 
not understood by the client software. (Likewise, PROFILE.CMD and 
PROFILE.BAT will not work for these clients.) Instead, you could associate a 
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logon script with each of those users with the above command. This would 
allow them to have automatic resource assignments at logon just as they 
would have by logging on to Microsoft LAN Manager, for example. 


Note: Depending on the number of users, you may have many different 
logon scripts. 


Be aware that Microsoft products do not understand aliases. Aliases are a LAN 
Server-unique concept. For Microsoft clients to access LAN Server resources, 
they must use the Universal Naming Convention (UNC) names, that is 

servername netname (sharename). Likewise, LAN Server clients must use 
UNC names to access resources on Microsoft servers. For example: 











NET USE X: SERVER1 APPS 

















Remember this point if you are creating logon scripts at the LAN Server for 
Microsoft clients. 
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In this section, we look at how Microsoft clients can access OS/2 LAN Server 4.0. 
(NetWare interoperability is discussed in “Interoperability Using the NetWare 
Client’ on page 188.) Figure 92 on page 165 shows the environment that we set 


up. 


The actions we attempted to perform are listed here: 


* While logged on to the same type of server, such as an NT workstation 
already logged on to the NTAS server, we tried using different resources 
from the OS/2 LAN Server 4.0 domain via the GUEST account. The access to 
the resources was attempted using the NET USE command. 


+ While logged on to the same type of server, such as an NT workstation 
already logged on to the NTAS server, we tried using different resources 
from the OS/2 LAN Server 4.0 domain via a normal user account with 
identical passwords. If the resource was protected by an additional 
password, we provided the required password information via the NET USE 
command. The access to the resources was attempted using the NET USE 
command. 


Logging on to the OS/2 LAN Server 4.0 domain from the different clients 
Checking for logon file assignments 
Checking for logon printer assignments 
Checking for access to resources via NET USE command 
* Checking for availability of public applications 


* Checking for parallel access of resources in both domains (for example, 
accessing NTAS resources and LS 4.0 resources at the same time) 
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Figure 92. Accessing OS/2 LAN Server from Different Clients 


In our test cases, we used the OS/2 LAN Server 4.0 Advanced (see Figure 92) 
and tested it with the following workstations: 


OS/2 LAN Manager 2.2 client 
+ Windows for Workgroups 3.11 client 
+ Windows NT 3.1 client 


Accessing OS/2 LAN Server 4.0 from a LAN Manager Client 


From a LAN Manager 2.2 client, you are able to use the resources of an OS/2 
LAN Server 4.0 domain. You can either: 


Log on directly to the LAN Server domain 


Provided you are already logged on to a LAN Manager domain, issue the 
NET USE command 


In the second case, you would be using either the GUEST account permissions (if 
your user ID is not known to the LAN Server domain), or you would be using the 
permissions given to your user ID. If you have a user ID set up on the LAN 
Server domain, be sure that the password is kept current and is the same as the 
password on the LAN Manager domain. Otherwise, you must specify the LAN 
Server domain password as part of the NET USE command. (For more 
information, see the NET USE command in the Commands and Utilities online 
reference or manual.) This is the same concept used when you access LAN 
Server resources of one domain while logged on to another domain. 


Unfortunately, you don't have access to a home directory in an OS/2 LAN Server 
4.0 domain from an OS/2 LAN Manager workstation. The way of handling the 
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home directory access is different in the LAN Server and LAN Manager 
environments. Also, LAN Server logon assignments are not used by LAN 
Manager clients. 


However, if you have set up logon scripts at the LAN Server for your LAN 
Manager users, these scripts will run when the users log on, as if they were 
logging on to a LAN Manager domain. Logon scripts can contain NET USE 
commands, to make resource assignments, other commands, and even REXX 
procedures. This is similar to the OS/2 LAN Server PROFILE.CMD and 
PROFILE.BAT files. You could have a NET USE to the home directory as part of 
the logon script to get around the home directory restriction. For more 
information, see the logon script description on page 163. 


Note: Remember that aliases are a LAN Server-unique concept not recognized 

by LAN Manager. If you include NET USE commands in the LAN Manager user 

logon script, you must use the full UNC name to point to the resource, that is, 
servername netname. 


Configuration Files 
The following are the configuration files we used in this environment. 


CONFIG.SYS: 


IFS=C: OS2 HPFS.IFS /CACHE:64 /CRECL:4 
ROTSHELL=C : \OS2\PMSHELL. EXE 
ET USER_INI=C:\O0S2\0S2.INI 

T SYSTEM_INI=C:\0S2\O0S2SYS.INI 
ET OS2_SHELL=C:\OS2\CMD. EXE 


ET AUTOSTART=PROGRAMS , TASKLIST, FOLDERS , CONNECTIONS 




































































ET RUNWORKPLACE=C: \OS2\PMSHELL. EXE 
T’ COMSPEC=C: \OS2\CMD. EXE 
ATH=C: \LANMAN\NETLIB;C:\IBMCOM\DLL; . ; 
OS2\DLL;C:\OS2\MDOS;C:\;C:\OS2\APPS\DLL; 
ET PATH=C: \LANMAN\NETPROG;C:\O0S2;C:\OS2\SYST 
S2\MDOS\WINOS2;C:\OS2\INSTALL;C:\; 
S2\MDOS;C:\OS2\APPS;C:\srvifsrq; 

ET DPATH=C&col\n.&\sl.LANMAN\NETPROG;C:\srvifsrq; 
IBMCOM;C:\0S2;C:\OS2\SYSTEM;C:\OS2\MDOS\WINOS2 ; 
OS2\INSTALL;C:\;C:\OS2\BITMAP;C:\; 

ET PROMPT=$i [Sp] 

ET HELP=C: \OS2\HELP;C:\OS2\HELP\TUTORIAL; 
ET GLOSSARY=C: \OS2\HELP\GLOSS; 



































H 
-wW 
as) 














Gl 


M; 






































ET IPF_KEYS=SBCS 
RIORITY_DISK_IO=YES 
ILES=20 
EVICE=C : \IBMCOM\PROTOCOL\LANPDD .OS2 
EVICE=C : \IBMCOM\PROTOCOL\LANVDD.OS2 
EVICE=C: \IBMCOM\LANMSGDD.OS2 /1I:C:\IBMCOM 
EVICE=C: \IBMCOM\PROTMAN.OS2 /I:C:\IBMCOM 
EVICE=C: \OS2\TESTCFG.SYS 
EVICE=C:\OS2\DOS.SYS 
EVICE=C:\0S2\PMDD.SYS 

UFFERS=30 

PL=YES 

SKCACHE=1024,LW,AC:C 

MAXWAIT=3 

EMMAN=SWAP, PROTECT 

PPATH=C: \OS2\SYSTEM 2048 2048 

REAK=OFF 
HREADS=256 
RINTMONBUFSIZE=134,134,134 
UNTRY=001,C:\0S2\SYSTEM\COUNTRY.SYS 
ET KEYS=ON 

EM SET DELDIR=C:\DELETE, 512; 
ASEDEV=PRINTO2.SYS 
ASEDEV=IBM2FLPY .ADD 
ASEDEV=IBM2ADSK .ADD 
ASEDEV=OS2DASD. DMD 
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SET BOOKSHELF=C: \OS2\BOOK 
SET EPMPATH=C: \OS2\APPS; 

REM DEVICE=C: \OS2\APPS\SASYNCDB. SYS 
P’ 

S. 

F 





























ROTECTONLY=NO 
HELL=C : \OS2\MDOS\COMMAND.COM C:\O0S2\MDOS 











EVICE=C: \OS2\MDOS\VEMM. SYS 
OS=LOW, NOUMB 
EVICE=C:\OS2\MDOS\VXMS.SYS /UMB 
EVICE=C: \OS2\MDOS\VDPMI .SYS 
EVICE=C: \OS2\MDOS\VDPX.SYS 
EVICE=C: \OS2\MDOS\VCDROM. SYS 
EVICE=C: \OS2\MDOS\VWIN. SYS 
EVICE=C: \OS2\PCMCIA.SYS 

EVICE=C: \OS2\MDOS\VPCMCIA.SYS 
EVICE=C: \OS2\MDOS\VMOUSE. SYS 
EVICE=C:\O0S2\POINTDD. SYS 

EVICE=C: \OS2\MOUSE.SYS 

EVICE=C: \OS2\COM.SYS 

EVICE=C: \OS2\MDOS\VCOM. SYS 
EPAGE=437,850 
EVINFO=KBD,US,C:\0S2\KEYBOARD.DCP 
EVINFO=SCR,VGA,C:\0S2\VIOTBL.DCP 
ET VIDEO_DEVICES=VIO_VGA 

ET VIO_VGA=DEVICE (BVHVGA) 

EVICE=C: \OS2\MDOS\VVGA. SYS 

























































































































































LANMAN 2.2a DO NOT MODIFY BETWEEN THESE LINES == LANMAN 2.2a = 
EVICE=C: \LANMAN\DRIVERS \PROTMAN\PROTMAN.OS2 /i:C:\LANMAN 

EVICE=C: \LANMAN\ DRIVERS \ TOKENRNG\ IBMTOK\ IBMTOK .OS2 

EVICE=C: \LANMAN\ DRIVERS \ PROTOCOL\NETBEUI\NETBEUL .OS2 

FS=C: \LANMAN\NETPROG\NETWKSTA.SYS /i:C:\LANMAN 

EM ==== LANMAN 2.2a == DO NOT MODIFY BETWEEN THESE LINES == LANMAN 2.2a 
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PROTOCOL.INI: 


[PROTMAN ] 
DRIVERNAME = PROTMANS 




















[NETBEUI_XIF] 

Drivername = netbeui$ 
SESSIONS = 40 

NCBS = 85 

BINDINGS = "IBMTOK_NIF" 











[IBMTOK_NIF] 
; protocol.ini section for the IBM Token Ring Adapter 


drivername = IBMTOKS 


Accessing OS/2 LAN Server from Windows for Workgroups 


In this section, we present an overview of Windows for Workgroups 3.11 and the 
installation/configuration needed in order to access OS/2 LAN Server 4.0. 
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Windows for Workgroups 3.11 





Figure 93. LAN Server & Windows for Workgroups Interoperability 


Windows for Workgroups 3.11 is a DOS-based application with network 
capabilities for a peer-to-peer or workgroup computing environment. Any 
Windows for Workgroup workstation can act as a server and client at the same 
time. 


There is no logon security for access network resources, as Windows for 
Workgroups uses share-level security. That is, each shared resource can have 
an associated password associated with it; any user in the network that knows 
the password can then access the resource. 


Windows for Workgroups works allows you to have many users who work at the 
same machine, each with their own setup and password list (PWL) file. The 
product stores locally all network connections in a file for each user that logs on 
at that workstation. Then each time you load Windows for Workgroups, you 
receive a logon screen to load your personal configuration. 


Note: DOS LAN Services (DLS) 4.0 product also implements this per-user 
configuration. In fact, you will find that DLS is similar to WFW in several ways to 
allow for compatibility between the two products. 


Windows for Workgroups Main Features 

Windows For Workgroups 3.11 includes the following features that allow users to 
easily work within the network environment. For more information on the 
features briefly presented here, see the Windows for Workgroups documentation. 


Sharing directories 
You share your disks and directories using the File Manager. The File 
Manager provides three access types for a resource: 


- Read only 


This allows other network users to access this resource and read the 
files (but not make changes to them). Also, you have the option to 
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associate a password with this resource. That is, the user will be able to 
access the resource only if they know the password; then they only have 
Read permission. If you do not supply a password, any user will be able 
to connect to the resource and have Read permission. 


- Full Access 


This allows others network users to access this resource for all 
permissions (such as Read, Write, and Delete). Here again, you have the 
option of associating a password with this resource so that the user will 
be able to access this resource only if they know the password. If you 

do not supply a password during the share creation process, any user 

will be able to connect to the resource for full access. 


- Depends on Password 


This allows the network users to access the resource with two different 
privileges, Read only or Full access. This is the most interesting access 
type because you have the option to supply two different passwords for 
the same resource, one password for Read only and another for Full 
access. The access privileges will be dependent on the password that 
the user provides when connecting to the resource. 


Sharing printers 


You share your printer resources using the Print Manager. Unlike the File 
Manager, the Print Manager does not have different kinds of access types. 
Also, you have the option to assign a password. 


Electronic Mail 


Mail is an application that you can use to exchange files and electronic 
messages with people on your network. 


Built-in FAX Application 


FAX is an application that you use to send and receive faxes, whether or not 
you are using the network. You have the option of sharing your fax with 
other users over the network. 


Scheduling Appointments Online with Schedule+ Application 


You can use the Schedule+ application to keep track of appointments and 
tasks, and to record notes to yourself. 


Sharing Clipboard Contents 


You can share information using the facilities of the Clipbook Viewer, for 
example, using the copy/paste functions. 


Network Applications 
- Chat 


You can use Chat to communicate with up to seven other workgroup 
members at a time by typing messages back and forth. 


- Net Watcher 


You can use Net Watcher to monitor how other people are using your 
shared resources. 


- WinMeter 


You can use WinMeter to monitor the performance of your system. 
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- Logon and logoff 


You can log on to or log off from Windows for Workgroups at any time. 
- Network Setup 


You can choose and configure some network definitions. 
- Remote Access Services 


The Remote Access Services function connects you to your office 
network from a remote site. Once connected, you can access network 
resources just as if you were directly connected to the network. 


To use Remote Access Services, you must have a Windows NT, LAN 


Manager, or other Remote Access server at your office accepting 
incoming calls. 


Configuration Steps for OS/2 LAN Server Access 


After Windows for Workgroups installation, in order to have access to the OS/2 
LAN Server 4.0, you need to make some changes as follows: 


a 


. To load Windows for Workgroups, type W1 
press Enter. 





[N at the command prompt and 


2. In the Main group, choose the Control Panel icon. 


3. In the Control Panel window, choose the Network icon. 


. in the Microsoft Windows Network panel, change the Workgroups field to an 
OS/2 LAN Server 4.0 domain name as shown in Figure 94. 


Microsoft Windows Network 





Computer Name: |LORDDART | 


Workgroup: LSDOMAINI234567 4 
Comment: Lord Darth Vader 


[ Logon Status 

















Currently logged on as USERO? 


Detault Logon Name: |USERO2 

















Ly 
Figure 94. Startup Settings Panel 
5. Click on Startup 
6. In the Startup Settings panel: 


Mark the Log On to Windows NT or LAN Manager Domain option 


Fill in Domain Name field with the LAN Server 4.0 domain name. 
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Startup Settings 


V Startup Options 
Log On at Startup Ed Ghosted Connections 
&] Enable Network DDE CZ] Enable WinPopup 





[ Options for Enterprise Networking 


EiLog 96 


Domain Name: |LSDOMAIN1234567 


LJ Don't Display Message on Successful Logon 














[ Performance Priority: 


Applications WEE Oe Resources 


Hun Fastest Shared Fastest 











Figure 95. Startup Settings Panel 
Now you are able to access the OS/2 LAN Server 4.0 as a regular user. 


During the Windows for Workgroups 3.11 load process, you will receive the logon 
screen shown in Figure 96. This is a local logon only. 


Welcome to Windows for ¥forkgroups 


Type a logon name and password to log on ae 
to the Microsoft Windows Network. Wit ibs yy 





Logon Name: USERO2 


Password: 











Figure 96. Windows for Workgroups Local Logon 


Following the local logon panel, you may receive another screen asking you 
about password list file creation (if there is not already a PWL file). The 
password list file is a file that holds all network connections and the related 
passwords done by a specific user during logon time. 


After logging on to Windows for Workgroups, you will receive the panel shown 

in Figure 97. This is where you can log on to the OS/2 LAN Server domain. It is 
important to remember that you will need to have an identical user ID on the 
OS/2 LAN Server 4.0 to log on there. 


Domain Logon 


Logon Name: USERO2 es ee 
Password: l LE L 














WL 
Domain: [Espomainizsase7_] (#] [fee 
YY 





Figure 97. Windows for Workgroups Domain Logon 
The user can access the network resources by specifying the server and the 
sharename (netname). 


Note: Normally, the alias name is the same as the sharename, however, with 
printers, this is not always the case. With printers, the sharename is the queue 
name; the alias name may be different. 
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After the modifications have been made, you can access the LAN Server 
resources in the following ways: 


+ Log on locally to Windows for Workgroups and access the server's resources 
using GUEST account privileges 


Log on locally to Windows for Workgroups using a user ID and password 
identical to your user ID and password on the LAN Server domain, and then 
access the server's resources using regular user privileges 


Log on directly to the LAN Server domain using the domain logon function of 
Windows for Workgroups 


After successfully logging on directly to the LAN Server domain: 


At logon, the logon script will run if one is set up on the server for your user 
ID. 


Note: If you have set up logon scripts at the LAN Server for your Windows 
for Workgroups users, these scripts will run when the users log on. Logon 
scripts can contain NET USE commands, to make resource assignments, 
other commands, and even REXX procedures. This is similar to the OS/2 
LAN Server PROFILE.CMD and PROFILE.BAT files. For more information, 
see the logon script description on page 163. 


+ You can use shared file and printer resources on the domain using NET USE 
or the File Manager/Printer Manager facilities, provided you have proper 
access permission. When you use the Printer Manager facilities to connect a 
printer, you also have to install a printer driver locally. 


You can do some management of the printer queues on the OS/2 LAN 
Server 4.0. 


* You can access resources in both environments at the same time, that is on 
OS/2 LAN Servers and Windows for Workgroups workstations (or other 
Microsoft servers such as NTAS and LAN Manager). 

You are not able to: 
Use aliases 
Receive your logon assignments or home directory 


+ Manage the LAN Server (for example, create users/groups or share server 
resources) 


« Use public network applications set up on the LAN Server 


Note: Be aware that Windows for Workgroups does not understand the LAN 
Server alias concept. To connect to a LAN Server resource from a Windows for 
Workgroups client, you must use the resource's UNC name, that is, 

servername netname (sharename). You cannot use the resource's alias 
name. 


Configuration Files 
Here are the configuration files used: 


CONFIG.SYS: 





DEVICEHIGH=C: \WINDOWS\HIMEM. SYS 

DEVICEHIGH=C : \WINDOWS\EMM386.EXE RAM 2048 
DOS=HIGH, UMB 
F 
B 





























ILES=30 
UFFERS=10 
STACKS=9 , 256 
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LASTDRIVE=Z 
DEVICE=C: \WINDOWS\SMARTDRV.EXE /DOUBLE_BUFFER 
DEVICE=C: \WINDOWS\IFSHLP.SYS 






































AUTOEXEC.BAT: 


@ECHO OFF 

C: \WINDOWS \SMARTDRV . EXE 
C:\WINDOWS\net start 

PROMPT Sp$g 
P. 
Ss 
L 














ATH=C : \WINDOWS ; C: \DOS; 
ET TEMP=C: \DOS 
H C:\DOS\MOUSE.COM /Y 




















SYSTEM.INI (in the Windows for Workgroups directory): 


[boot] 

shell=progman.exe 
network. drv=wfwnet.drv 
mouse. drv=mouse.drv 
language.d1ll= 

sound. drv=mmsound.drv 
comm.drv=comm.drv 
keyboard. drv=keyboard.drv 
system.drv=system.drv 
386grabber=vga.3gr 
oemfonts.fon=vgaoem. fon 
fixedfon.fon=vgafix. fon 
fonts.fon=vgasys.fon 
display.drv=vga.drv 
drivers=mmsystem.d11 





keyboard] 
subtype= 
type=4 
keyboard.d11l= 
oemansi.bin= 


[boot.description] 

keyboard.typ=Enhanced 101 or 102 key US and Non US keyboards 
mouse.drv=Microsoft, or IBM PS/2 
language.dll=English (American) 

system.drv=IBM PS/2 Model P70 

codepage=437 

woafont.fon=English (437) 

aspect=100,96,96 

display.drv=VGA 

network.drv=Microsoft Windows Network (version 3.11) 
secondnet.drv=No Additional Network Installed 








[386Enh] 
device=*vpd 
mouse=*vmd 
ebios=*ebios 
woafont=dosapp. fon 

display=*vddvga 

EGA8 0WOA . FON=EGA8 0WOA. FON 

EGA40WOA. FON=EGA40WOA. FON 

CGA8 0WOA . FON=CGA8 0WOA . FON 

CGA40WOA . FON=CGA40WOA. FON 

keyboard=*vkd 
network=*vnetbios, *vwc, vnetsup.386,vredir.386,vserver.386 
netheapsize=20 

device=*vcd 

device=*vpicd 

device=*vtd 

device=*reboot 

device=*vdmad 

device=*vsd 

device=*v86mmgr 

device=*pageswap 

device=*dosmgr 
device=*vmpoll 
device=*wshell 
device=* PAGEFILE 




















Chapter 9. LAN Server 4.0 Interoperability 


173 


device=* BLOCKDEV 
device=*vfd 
device=*parity 
device=*biosxlat 
device=*vmcpd 
device=*combuff 
device=*cdpscsi 
device=vtdapi.386 
device=vpmtd.386 
device=vcomm. 386 
device=serial .386 
device=lpt.386 
device=ifsmgr.386 
device=vcache. 386 
device=vshare. 386 
local=CON 
FileSysChange=off 
COM3 Irq=4 

COM3 Base=03E8 
comM4Irq=3 
COM4Base=02E8 

PagingFile=C: \WINDOWS\WIN386.SWP 
MaxPagingFileSize=8543 
netmisc=ndis.386,ndis2sup.386 
netcard=ibmtok.386 
transport=nwlink.386,nwnblink.386,netbeui.386 
InDOSPolling=FALSE 
netcard3= 











[NonWindowsApp] 
localtsrs=dosedit,ced 


[vcache] 
minfilecache=512 


[mci] 
WaveAudio=mciwave.drv 
Sequencer=mciseq.drv 
CDAudio=mcicda.drv 


[drivers] 
timer=timer.drv 
midimapper=midimap.drv 


[DDEShares ] 

CHATS=winchat,chat,,31,,0,,0,0,0 
SCHATS=winchat, chat, ,31,,0,,0,0,0 
CLPBKS=clipsrv, system, ,31,,0,,0,0, 
HEARTSS=mshearts,hearts,,15,,0,,0 








0 
,0,0 
[Network] 
winnet=wfwnet/00025100 
multinet=nonet 
FileSharing=Yes 
PrintSharing=Yes 
LogonDisconnected=Yes 
EnableSharing=Yes 
UserName=USERO2 
Workgroup=LSDOMAIN1234567 
ComputerName=MILTONP. 
Comment=Milton P. Cruz Jr. 
logonvalidated=yes 
cachethispassword=no 
AutoLogon=Yes 
StartMessaging=No 
LoadNetDDE=Yes 

LMLogon=1 
LogonDomain=LSDOMAIN1234567 
DomainLogonMessage=Yes 

















[network drivers] 
netcard=ibmtok.dos 
transport=*netbeui,ndishlp.sys 
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devdir=C: \WINDOWS 
LoadRMDrivers=No 


[NWNBLINK] 
LANABASE=0 








[Password Lists] 
*Shares=C: \WINDOWS\Share000.PWL 


PROTOCOL.INI (in the Windows for Workgroups directory): 


[network. setup] 

version=0x3110 
netcard=msSibmtr4a,1,MSSIBMTR4A, 3 
transport=ms$nwlinknb, NWLINK 
transport=ms$netbeui , NETBEUIL 
transport=ms$ndishlp,MSSNDISHLP 
lana0=ms$ibmtr4a,1,ms$nwlinknb 
lanal=ms$ibmtr4a,1,ms$netbeui 
lana2=ms$ibmtr4a,1,ms$ndishlp 














MSSIBMTR4A] 


DriverName=IBMTOKS 
IBMTOK] 
Adapters=MSSIBMTR4A 


NWLINK] 


BINDINGS=MSSIBMTR4A 
NETBEUT ] 
BINDINGS=MSSIBMTR4A 
LANABASE=1 
DriverName=netbeuiS 
SESSIONS=10 

NCBS=12 





























[protman] 
DriverName=PROTMANS 
PRIORITY=MSSNDISHLP 


[MSSNDISHLP] 


DriverName=ndishlps$ 
BINDINGS=MSSIBMTR4A 


Accessing OS/2 LAN Server from a Windows NT Client 


In this section, we introduce Microsoft Windows NT and discuss how you can 
access resources on an OS/2 LAN Server 4.0 from this client type. 
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Figure 98. Windows NT Client Accessing OS/2 LAN Server 4.0 


Windows NT is the Microsoft preemptive multitasking, 32-bit operating system. 
Windows NT integrates security and network capabilities as a part of the base 
operating system. The product works with two models of networking, 
peer-to-peer, sometimes called workgroup computing, and client-server. A major 
difference between them is the user account database location and 
management. In the peer-to-peer model, each Windows NT workstation has its 
own user account database locally stored in the workstation hard disk, and the 
management is local only. Using Windows NT in the client-server environment, 
you will have two different kinds of the nodes as follows: 


1. Server running the Windows NT Advanced Server (NTAS) 


2. Workstation running the Windows NT operating system 


The Windows NT operating system has the ability to run programs written for 
other operating systems, such as DOS, Microsoft Windows 3.1 and OS/2 1.x 
(character text mode only). Also the product works with three different types of 
file systems: the File Allocation Table (FAT), the High Performance File System 
(HPFS) and the Windows NT File System (NTFS). 


Figure 99 on page 177 shows the Windows NT network model. Explanations of 
the components follows. 
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Figure 99. Windows NT Network Model 


* Transport Driver Interface (TDI) 


For communication between the session and transport layers of the OSI 
Reference Model, Microsoft has developed and supports the Transport Driver 
Interface (TDI). On a Windows NT computer, the server and redirection 
processes communicate with the transport layer by using the TDI interface. 
The purpose of the TDI is to provide a common interface for networking 
components that communicate at the session level. The TDI implementation 
breaks the NetBIOS session limit barrier of 254. The limit of the NetBIOS 
sessions it is dependent on the computer memory. 


NetBIOS Frame (NBF) 


The version of NetBEUI shipping with Windows NT is NetBEUI 3.0, and is 
called the NetBIOS Frame (NBF) protocol. NBF conforms to the Transport 
Drive Interface (TDI), unlike earlier versions of NetBEUI that interface to 
NetBIOS. NBF is completely compatible and interoperable with NetBEUI 
shipped with past Microsoft networking products. 


Network Driver Interface Specification (NDIS) 


Windows NT is compliant with the NDIS 3.0 specification. Unlike previous 
NDIS implementations, Windows NT does not need a protocol manager 
module to link the various components and layers together. Instead, 
Windows NT uses the information in the registry and a small piece of code 
called the NDIS wrapper, which surrounds the network adapter card driver. 
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+ STREAMS 


Windows NT supports STREAMS-compliant protocols. The following two 
protocols are included with Windows NT and STREAMS as an intermediary 
between the protocol and the next interface layer (NDIS on the bottom and 
TDI on the top): 


- TCP/IP 
TCP/IP is the popular routable protocol for WANs. 
- NWLink 


NWLink is an NDIS-compliant version of the Internetwork Packet 
Exchange (IPX) compatible protocol. It can be used to establish 
connections between Windows NT computers and NetWare servers. 
However, to connect to a NetWare server, you need also the NetWare 
Requester for NT delivered from Novell. 


Data Link Control (DLC) 


The Microsoft Data Link Control (DLC) provides an interface for access to 
mainframes and network attached printers, like the HP LaserJet. 


Note: The Windows NT Advanced Server also includes the AppleTalk protocol, 
with services for Macintosh. 


Windows NT does not use separate configurations files (such as CONFIG.SYS, 
AUTOEXEC.BAT, WIN.INI, and PROTOCOL.INI). Instead, Windows NT uses a 
structure called the registry. The registry is a structure with four subtrees of 
keys that contain per computer and per user databases. The per computer 
database includes the information about hardware, such as bus type, system 
memory, device drivers, and startup control data. It includes the information 
about the software installed on the specific computer too. The per-user 
information includes the information in user profiles, such as desktop settings, 
individual preferences for certain software, and personal printer network 
settings. The main advantages of the registry is that all configuration is in one 
place, and you can have different configurations for different users at the same 
workstation. 


AUTOEXEC.BAT, CONFIG.SYS and .INI files exist to provide compatibility with 
applications created for DOS and OS/2. Windows 3.1 NT does not update and 
maintain these files. 


We were unable to log on directly to the OS/2 LAN Server. However, we could 
use resources on the server by creating local user name (and password) on the 
Windows NT machine which is identical to a user ID (and password) on the OS/2 
LAN Server. If the Windows NT user name was unknown to the OS/2 LAN 
Server, then we had, at the minimum, guest privileges; that is, we had 
permissions assigned to the GUEST user ID. 


To treat the Windows NT user as a user known on your domain then, you must 
create a local user name identical to the user ID on the LAN Server. Here are 
the necessary steps to create a new user on the Windows NT workstation: 


1. Load Windows NT, and log on locally with administrator privileges 


2. Go to Administrative Tools program group and load the User Manager 
program 


Inside OS/2 LAN Server 4.0 


3. Click on the User object and choose New User. Fill in all fields on the 


screen, taking care to use the same password that is used for this user on 
the LAN Server domain. 


Now you have a local user identical to a user on the LAN Server domain. When 
you log on locally to Windows NT, you are able to connect to a resource located 
on the OS/2 LAN Server and use it with the same access privileges as a regular 
user. However, it is important to remember that if you change the password on 
the server, also change the local user password so they continue to match. 


After these modifications you will be able to: 


* Access the server using guest privileges 


* Access the server using regular user privileges 


Note: Even if the user ID is set up as an administrator, we were unable to 
perform most administrator tasks from a Windows NT workstation. 


Do some print queue management on OS/2 LAN Server 


You are not to able to: 


Use aliases 

Log on to the OS/2 LAN Server domain 
Receive logon assignments or logon scripts 
Use public network applications 


Manage the users and resources on the server 





OS/2 LAN Requester Accessing Microsoft Servers 


Here we discuss how you can access different kinds of Microsoft servers using 
an OS/2 LAN Requester 4.0. We tested the use of an OS/2 LAN Requester 4.0 to 
perform the following actions: 


1. 


oN Oa fF WwW 


While logged on to the OS/2 LAN Server 4.0 domain, access resources on 
the other domains or servers using the guest account. The access to the 
resources was done by the NET USE command. 


. While logged on to the OS/2 LAN Server 4.0 domain, access resources on 


the other domains or servers via a normal user account with identical user 
IDs and passwords (or by providing a separate password via the NET USE 
command). The access to the resources has been done by the NET USE 
command. 


. Log on to the other domain or server 

. Check for logon file assignments 

. Check for logon printer assignments 

. Check for access to resources via NET USE command 
. Check for availability of public applications 


. Parallel access of resources in both domains (such as NTAS resources and 


LAN Server 4.0 resources at the same time) 
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Figure 100. Accessing Different Servers OS/2 LAN Server Client 


In our tests, we used the OS/2 LAN Server Advanced Version 4.0 client (see 
Figure 100) to have access to the following Microsoft servers. (NetWare 
interoperability is discussed in “Interoperability Using the NetWare Client” on 
page 188.) 


1. OS/2 LAN Server 4.0 

2. OS/2 LAN Manager 2.2 

3. Windows NT Advanced Server (NTAS) 3.1 
4. Windows for Workgroups 3.11 

5. OS/2 LAN Server 3.0 


Accessing Microsoft LAN Manager from an OS/2 Client 


Here we discuss accessing a Microsoft LAN Manager server from an OS/2 LAN 
Requester. 
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Figure 101. Accessing OS/2 LAN Manager from an OS/2 Client 


It is possible to access the resources of a Microsoft LAN Manager domain in 
three different ways, as follows: 


+ After you are logged on to an OS/2 LAN Server 4.0 domain, you may isse a 
NET USE command to access resources in a LAN Manager domain using the 
GUEST account. 


+ After you are logged on to an OS/2 LS 4.0 domain, you may also issue a NET 
USE command to access a resource in a LAN Manager domain using a 
regular user ID. This can be done if you have defined the same user ID 
within the LAN Manager and OS/2 LAN Server domains. The passwords 
should also be identical in both domains. 


Note: If you choose to make the passwords different, then you can still 
access the resources in the LAN Manager domain by appending the correct 
password at the end of the NET USE command. For more information, see 
the NET USE command in the Commands and Utilities online reference or 
manual. 


Directly log on to the LAN Manager domain using the OS/2 LAN Requester 
software. Simply issue a LOGON command from an OS/2 command session 
or logon via a logon window, specifying the LAN Manager domain name. If 
there is a logon script set up for the user ID, this will run. Once logged on to 
the LAN Manager domain, you can also access LAN Server 4.0 resources via 
the NET USE command (using either the GUEST account or your regular user 
ID). 


If you are set up as an administrator on the LAN Manager domain, you can use 
the NET ADMIN command to do administrator functions, but remember to use 
the LAN Manager command syntax. You can use the LAN Server GUI to do very 
limited group management (other functions can be viewed but not changed from 
the GUl). 
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As shown here, you can be connected to resources on both types of servers, 
regardless of which domain you logged on to: 


[C: Jnet use 
















































































Status Local name Remote name 

OK F \\LS40SERV\DDISK 
OK H: \\LMSERV\OS2DIR 

OK I: \\LS40SERV\DOSDIR 
OK P: \\LS40SERV\CDISK 
OK T: \\LMSERV\DISKTEST 
OK LPT1 \\LS40SERV\IBM4019 
OK LPT2 \\LMSERV\IBM4029 




















The command completed successfully. 


You are not able to: 
Use aliases, which are unique to LAN Server 


You must specify both the server name and the sharename (netname) when 
accessing a LAN Manager resource. 


Receive a LAN Manager home directory at logon 


Home directories are not supported using a LAN Server client within a LAN 
Manager domain, because the set up is different across the two products. 
However, you could make this part of the logon script. 


Do most administration functions on the LAN Manager domain 


Most administration on a LAN Manager domain from a LAN Server client is 
restricted, although we could use and change the group definitions. Within 
the other functions, we were able to see the definitions, but could not change 
them in any way. 


Accessing Windows NTAS from an OS/2 Client 


In this section, we discuss how to access a Windows NT Advanced Server 
(NTAS) from an OS/2 LAN Requester 4.0 and the restrictions that apply to this 
configuration. 
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Figure 102. Accessing Windows NTAS from an OS/2 Client 
Considerations for accessing NTAS are the same as for accessing Microsoft LAN 
Manager except for the following: 

Logon scripts do not work accessing NTAS 3.1 from an OS/2 LAN Requester 


NET ADMIN cannot be used to administer NTAS, because NTAS does not 
recognize this command. Very limited user/group administration can be 
done from the GUI. 


For other considerations, see the comments in “Accessing Microsoft LAN 
Manager from an OS/2 Client” on page 180. 


Accessing Windows for Workgroups from an OS/2 Client 


In this part we are discussing how to access a Windows for Workgroups server 
from an OS/2 LAN Services 4.0 client and what kind of restrictions apply to this 
configuration. 
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Figure 103. Accessing Windows for Workgroups from an OS/2 Client 


The following are restrictions when accessing a Windows for Workgroups 
workstation from an OS/2 LAN Requester: 


* You cannot log on to a Windows for Workgroups workstation. 


If you want to access resources, you can do that by using a NET USE 
command and the full UNC name ( WFWNAME RESOURCE). Resource 
aliases do not exist. 


It is possible to restrict the use of a resource by defining a resource 
password when it is shared. Then users attempting to access this resource 
must provide the correct password as part of the NET USE command. There 
are only two levels of security for directories: 


- Read-Only 
- Full Access 


It is not possible to do any administrative definitions for your Windows for 
Workgroups server from your OS/2 LAN Requester 4.0 client. 


These restrictions also apply when using a DOS LAN Services 4.0 client to 
access a Windows for Workgroups workstation. 


DOS LAN Services 4.0 Clients Accessing Microsoft Servers 


Here we will discuss how interoperability in our LAN environment can be 
achieved using the DOS LAN Services 4.0 Client. The following is a picture 
describing our environment: 
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Figure 104. DOS LAN Services Interoperability 


The DOS LAN Services client in our network environment was configured with 
the following software : 


IBM PC DOS 6.3 
IBM DOS LAN Services Client 4.0 


The DOS LAN Services client was tested for interoperability with OS/2 LAN 
Manager, Windows NTAS, and Windows For Workgroups. Interoperability with 
Novell NetWare is discussed in “Interoperability Using the NetWare Client” on 
page 188. 


In each server test environment, DOS LAN Services was tested for the following: 


Logon capability 

Access to logon file assignments 

Access to printer assignments 

Access to resources using the NET USE command 
Concurrent access to different domains 


These tests were carried out by issuing commands at the DOS command line 
and using the DOS LAN Services GUI interface. 
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Here we will discuss the interoperability of a DOS LAN Services 4.0 client and 
Microsoft LAN Manager 2.2. 
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Figure 105. DOS LAN Services and Microsoft LAN Manager 


We found that we were able to perform the following functions with DOS LAN 
Services: 


Log on to the LAN Manager domain is allowed with an administrator or user 
account. If a logon script exists for the user, it will run. 


Once logged on to the LAN Manager domain, you can issue the NET USE 
command or use the DOS LAN Services GUI to access file and printer 
resources located on the LAN Manager domain. 


You can use the NET USE command to access resources outside of the LAN 
Manager domain. Within the GUI, it is also possible to connect to a shared 
resource outside of the LAN Manager domain. 


However, remember that aliases, which are unique to LAN Server, do not 
exist under LAN Manager. You must use the full UNC name (server plus 
sharename) when connecting to the resource, for example: 





NET USE T: LMSRV TEMP 














+ When logged on to a LAN Server 4.0 domain, it is possible to access file and 


printer resources on the OS/2 LAN Manager with the GUEST account by 
using the NET USE command. Within the GUI, it was also possible to 
connect to a resource on the LAN Manager domain. 


Public applications are not available under LAN Manager. 


* Administration functions can be performed via the NET ADMIN command, but 


remember to use the LAN Manager command line syntax. 
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Interoperability with Windows NT 


DOS LAN Services was tested for access to a Windows NT Advanced Server. 


Microsoft Windows NT 
OS/2 LAN Server 4.0 Advanced Server 
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Figure 106. DOS LAN Services and Windows NT 


The following describes our results: 


+ Logon to a Windows NT Advanced Server as a user or administrator is 
possible. 


+ When logged on to an NTAS domain, it is possible to access file and printer 
resources using the GUI interface and the NET USE command (and the full 
UNC name). 


You can access file and printer resources outside the Windows NT domain 
with the NET USE command. Using the GUI interface, it is also possible to 
access file and printer resources outside of the Windows NT domain. 


* When logged on to the OS/2 LAN Server domain, you can use the NET USE 
command to access file and printer resources on the Windows NT server 
using the GUEST account. It is also possible to connect to a resource on the 
Windows NT domain from within the GUI interface. 


It is not possible to administer a Windows NT server using DOS LAN 
Services. 


Public applications are not supported by Windows NT Advanced Server. 


* Aliases, which are unique to LAN Server, are not supported. You must 
specify both the server and the sharename when connecting to the NTAS 
resource. 
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Interoperability with Windows For Workgroups 


This section describes what sort of access we have to Windows for Workgroups 
workstation from DOS LAN Services v4.0. 
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Figure 107. DOS LAN Services and Windows For Workgroups 


These are our results: 
* You cannot log on to a Windows For Workgroups workstation. 


* You can access resources on a Windows for Workgroups workstation by 
using the NET USE command and specifying the full UNC name 
( WFWNAME RESOURCE). 


¢ There are no public applications. 


+ Administrative functions of the Windows for Workgroups server cannot be 
performed from a DOS LAN Services client. 








Interoperability Using the NetWare Client 


This section will describe the interoperability of the OS/2 LAN Requester and 
DOS LAN Services clients while concurrently accessing an OS/2 LAN Server and 
a NetWare server. This requires setting up a dual requester environment (that 
is, both types of clients are installed). 


The following is a picture that shows the environment we are concerned with: 
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Figure 108. Dual Requester Environment 


To achieve this, the workstation was configured with the following environments : 


OS/2 LAN Requester 4.0 and the Novell NetWare OS/2 Client v2.10 running 
under OS/2 Warp, Version 3. 


DOS LAN Services 4.0 and the Novell NetWare DOS Requester (VLM client) 
running under DOS 6.3. 


DOS LAN Services 4.0 and the Novell NetWare DOS shell (NETX client) 
running under DOS 6.3. 


In each case, the workstation was configured with an IBM Token-Ring Adapter 
16/4. 


Note: The OS/2 LAN Requester and DOS LAN Services clients were also used 

to provide simultaneous connectivity to the LAN Manager Server, Windows NTAS 
and Windows for Workgroups, as well as the OS/2 LAN Server 4.0 and NetWare 
server. 


The OS/2 interoperability environment also has been tested and documented in 
NetWare Client for OS/2 Installation and Configuration. For more information, 
refer to this redbook. 


First, we will provide an overview on how to configure the workstation client to 


achieve coexistence between the two types of clients and then talk about any 
interoperability issues. 
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Coexistence Methods 
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IBM OS/2 LAN Requester and DOS LAN Services use a different network 
transport mechanism to that of the NetWare OS/2 and DOS clients. The IBM 
clients use the Network Driver Interface Specification (NDIS) and the NetWare 
clients use Open Data-Link Interface (ODI). Here we discuss the methods that 
allow the IBM and NetWare clients to coexist. 


ODI2NDI Driver 

ODI2NDI is a driver provided by IBM. ODI2NDI allows the ODI protocol stacks 
provided by the NetWare OS/2 Client to operate with network adapter drivers 
that comply with NDIS. ODI2NDI is the preferred method to enable coexistence 
of NDIS and ODI protocol drivers in an OS/2 environment for these reasons: 


It is the most flexible and easiest interoperability configuration. ODI2NDI is 
installed and configured by MPTS without manual changes. 


It provides better performance than the LANSUP and ODINSUP methods. 


+ It does not require any specific definitions in the NET.CFG file. 
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Figure 109. ODI to NDIS (ODI2NDI) Driver for LAN Server and NetWare Coexistence 


ODINSUP Driver 

ODINSUP (Open Data-Link Interface/Network Driver Interface Specification 
Support) is an ODI driver that allows an NDIS protocol driver and an ODI 
protocol driver to coexist. ODINSUP.SYS is provided with the NetWare OS/2 
Client. ODINSUP.COM is provided with the NetWare DOS Client. 


The ODINSUP replaces the NDIS LAN adapter driver but provides an interface 
that allows the NDIS protocol to have access to the LAN adapter through the ODI 
network driver interface. Unfortunately, it gives a lower performance to the OS/2 
LAN Server client than the LANSUP or ODI2NDI method. 
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Figure 110. ODINSUP Driver for LAN Server and NetWare Coexistence 


Figure 110 shows how ODINSUP is included in the ODI stack, and how the NDIS 
interface is running on top of ODINSUP. 


LANSUP Driver 

LANSUP (LAN Adapter Network Driver Interface Specification Support) is a driver 
supplied by Novell and is included with the NetWare clients for OS/2 and DOS. 
This driver allows ODI protocols to use the IEEE 802.2 interface that is provided 
by MPTS and the IBM LAN Support Program. 


LANSUP can be used with NDIS drivers for Token Ring, Ethernet and PC Network 
Il adapters. It maintains the protocol stacks and NDIS drivers configured through 
MPTS in an OS/2 environment and the LAN Support Program drivers in a DOS 
environment. Therefore this co-existence method does not require much further 
configuration once MPTS or the LAN Support Program has been installed and 
configured. 


Figure 111 on page 192 shows how LANSUP integrates the NetWare Client into 
an IEEE 802.2 environment. 
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Figure 111. LANSUP Driver for LAN Server and NetWare Coexistence 


OS/2 Client Coexistence Using ODI2NDI 


ODI2NDI is a driver provided by IBM in the MPTS product that allows the 
NetWare Client for OS/2 to run over the NDIS interface. Figure 109 on page 190 
shows how the ODI drivers talk to the ODI2NDI driver that provides an interface 
to NDIS. 


Note: Although there are three methods of coexistence between OS/2 LAN 
Requester 4.0 and the NetWare OS/2 Client, we concentrate here on ODI2NDI, 
since it is the recommended and best method of interoperability for OS/2. 


Installation Steps 
1. Install OS/2, MPTS and OS/2 LAN Requester. Reboot. 


At this stage, do not install the IBM NetWare Requester protocol support 
option, just the NetBIOS protocol (and protocols you may need for other 
applications). 


2. Install the NetWare OS/2 Client. When you get to the Choose the ODI LAN 
Driver screen, it does not really matter which driver you choose here, as this 
driver will be replaced when you run the MPTS configuration utility again to 
bind the NetWare Requester protocol to the LAN adapter. Do not reboot 
after installing the NetWare OS/2 Client as there will be conflicting 
statements in your CONFIG.SYS until you rerun MPTS to install ODI2NDI. 


3. After completing the installation of the NetWare Client, exit out of the 
installation utility and run the MPTS configuration utility before rebooting. 


4. In the MPTS configuration utility, add the NetWare Requester support to your 
adapter. This is adding the ODI2NDI driver. 


5. Edit the NetWare Requester protocol option to include the locally 
administered address or burnt-in address of the LAN adapter. This address 
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should be the same as the address configured for the NetBIOS protocol. 
Take a look at the IBMCOM LANTRAN.LOG file if you are not sure what 
address is being used. 


Prefix the address with either T for a Token Ring card or I if an Ethernet 
card was being used. 


. Save your configuration and exit out of MPTS. 


You do not need to configure a NET.CFG, however you may do so if you wish 
to make some changes to the default environment. For example, if you will 
not be accessing NetWare 4.x servers, you may want to add: 


netware requester 
directory services off 





to improve performance. 


8. Shutdown and reboot the workstation for the changes to take effect. 


Here are the relevant details of the CONFIG.SYS and listings of the 
PROTOCOL.INI and NET.CFG used in our configuration: 


CONFIG.SYS 


EM --- NetWare Requester statements BEGIN --- 
ET NWLANGUAGE=ENGLISH 




















EVICE=C: \NETWARE\LSL.SYS 








UN=C : \NETWARE \ DDAEMON . EXE 























EVICE=C: \IBMCOM\PROTOCOL\ODI2NDI .O0S2 





EM -- ODI-Driver Files BEGIN -- 








EM DEVICE=C: \NETWARE\TOKEN. SYS 




















EM -- ODI-Driver Files END -- 














EVICE=C: \NETWARE\ROUTE. SYS 








EVICE=C: \NETWARE\IPX.SYS 

















EVICE=C: \NETWARE\SPX.SYS 





UN=C : \NETWARE\SPDAEMON. EXE 
em DEVICE=C: \NETWARE\NMPIPE.SYS 

em DEVICE=C: \NETWARE\NPSERVER. SYS 
em RUN=C: \NETWARE\NPDAEMON. EXE 










































































EVICE=C: \NETWARE\NWREQ. SYS 

















FS=C: \NETWARE\NWIFS.IFS 
UN=C : \NETWARE\NWDAEMON . EXE 
em DEVICE=C: \NETWARE\NETBIOS.SYS 
em RUN=C: \NETWARE\NBDAEMON. EXE 










































































EVICE=C: \OS2\MDOS\LPTDD. SYS 








AUKRRAHOAKRKR DVVVADAVGVAGHDA 





U 





EM --- NetWare Requester statements END --- 





ROTOCOL.INI 
[PROT_MAN] 





DRIVERNAME = PROTMANS 











[IBMLXCFG] 





LANDD_nif = LANDD.NIF 
NETBEUI_nif = NETBEUI.NIF 
ODI2NDI_nif = ODI2NDI.NIF 
IBMTOK_nif = IBMTOK.nif 




















ETBIOS] 


DriverName = netbioss$ 
ADAPTERO = netbeuiS,0 





[LANDD_nif] 


DriverName = LANDDS 
Bindings = IBMTOK_nif 
NETADDRESS = "T1O0005AECB524" 
ETHERAND_TYPE = "I" 
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SYSTEM_KEY = 0x0 
OPEN_OPTIONS = 0x2000 
TRACE = 0x0 

LINKS = 8 

MAX_SAPS = 3 











USERS = 3 

Tr TICK Gl = 255 
T1_TICK_G1 = 15 
T2_TICK_G1 = 3 
TI_TICK_G2 = 255 
T1_TICK_G2 = 25 
T2_TICK_G2 = 10 

















MINTRANSMITS = 2 
TCBS = 64 

GDTS = 30 
ELEMENTS = 800 














[NETBEUI_nif] 











DriverName = netbeui$ 
Bindings = IBMTOK_nif 
ETADDRESS = "T10005AECB524" 
ERAND_TYPE = "I" 
SEADDRREV = "YES" 

EMASK = 0x0 

IONS = 140 














cr 
fan 
ea 
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S = 35 

LECTORS = 15 
EMAXDATAGRAM = "NO" 
DAPTRATE = 1000 
INDOWERRORS = 0 
MAXDATARCV = 4168 

TI = 30000 

T1 = 1000 

T2 = 200 
MAXIN = 1 
MAXOUT = 1 
NETBIOSTIMEOUT = 500 
NETBIOSRETRIES = 8 
NAMECACHE = 1000 
RNDOPTION = 0 
PIGGYBACKACKS 
DATAGRAMPACKET 
PACKETS = 350 
LOOPPACKETS = 8 
PIPELINE = 5 
MAXTRANSMITS = 
MINTRANSMITS 
DLCRETRIES = 
FCPRIORITY = 
NETFLAGS = 0x 














2eEGBgauoaHsE 
Ww 
THnn 
iT] 
i) 
i) 
uo 




















GW 


























I 
Woe 
































0 








1 
5 
0 





[ODI2NDI_nif] 


DriverName = odi2ndis$ 
Bindings = IBMTOK_nif 
























































NETADDRESS = "T10005AECB524" 
TOKEN-RING = "yes" 
TOKEN-RING_SNAP = "no" 
ETHERNET_802.3 = "no" 
ETHERNET_802.2 = "no" 
ETHERNET_II = "no" 
ETHERNET_SNAP = "no" 

TRACE = 0x0 








[IBMTOK_nif] 


DriverName = IBMTOKS$ 
ADAPTER = "PRIMARY" 
MAXTRANSMITS = 6 
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ECVBUFS = 2 
ECVBUFSIZE = 256 
XMITBUFS = 1 


R 
R 








NET.CFG 


NetWare Requester 
Preferred Server INTEROP 





DOS LAN Services and NetWare DOS Requester Coexistence 


The NetWare DOS Requester (VLM.EXE) includes a redirector that services 
requests made from DOS for NetWare services. 


The requester differs from the NetWare DOS shell (NETX.EXE) in that the DOS 
shell intercepts all DOS interrupt requests and then decides if the request is for 
a service provided by DOS or by NetWare. 


The DOS Requester is implemented by loading a single module which has the 
ability to load several individual modules called Virtual Loadable Modules 
(VLMs). A VLM is a modular executable program with a set of logically grouped 
features or APIs. They also provide backward compatibility with the older 
NetWare shell. 


There are two types of VLMs: 


Child VLMs 
+ Multiplexors 


The documentation provided with the NetWare operating system discusses the 
function of the Child VLMs and Multiplexors in detail. 


The DOS Requester requires that the network transport layer is established 
before it can communicate with the NetWare server. The transport layer is 
implemented using the ODI drivers. 


Two methods of achieving coexistence between the DOS LAN Services and 
NetWare DOS Requester (VLMs) were tested: 


Using the DOS ODINSUP protocol driver 
Using the DOS LANSUP driver 


The NetWare client software used in our testing environment was supplied with 
the NetWare 4.02. 


Implementing ODINSUP 

In this configuration, the ODINSUP driver replaces the NDIS LAN adapter driver, 
providing an interface that allows the NDIS protocol to have access to the LAN 
adapter through the ODI network driver interface. The DOS ODINSUP driver is 
supplied with the NetWare DOS Client kit. Figure 110 on page 191 shows how 
ODINSUP is included in the ODI stack, and how the NDIS interface is running on 
top of ODINSUP. 


Installation steps for ODINSUP: The following installation steps were used in our 
testing environment. 
1. Install DOS LAN Services configured for NetBEUI. 


2. Install the NetWare DOS LAN Requester configured for IBM Token-Ring. This 
installation process creates a batch file called STARTNET.BAT that will be 
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used to start the NetWare DOS Requester. It will also create/modify the 
NET.CFG file. Both files are located in the client's install destination 
subdirectory (usually called NWCLIENT). 


3. Changes must be manually made to the CONFIG.SYS, AUTOEXEC.BAT, 
PROTOCOL.INI, NET.CFG and STARTNET.BAT. 
CONFIG.SYS changes 


In CONFIG.SYS, you need to disable the NDIS adapter driver. To do this, locate 
the line that loads the NDIS LAN adapter, and either delete the line or add the 
REM statement at the beginning of the line. For example: 


rem device=c: net ibmtok.sys 





AUTOEXEC.BAT changes 


Prevent the DOS LAN Services Client from starting in AUTOEXEC.BAT by either 
deleting or adding a REM statement to the line. The reason for doing this is to 
prevent a drive mapping problem that is discussed in “Hints and Tips” on 

page 201 For example: 


rem c: net net start 
PROTOCOL.INI changes 


In the PROTOCOL.INI, ensure that the NDIS protocol driver binds to the ODI 
adapter driver. Comment out or delete the bindings for the NDIS driver and add 
a bindings statement to use the ODI driver. 








: BINDINGS = IBMSIBMTR4A 
BINDINGS = TOKEN 


















































NET.CFG changes 
Edit the NET.CFG to bind the LAN driver and its frame types to the ODINSUP 
protocol driver. 


1. Add a link driver statement, if you do not already have one, to your NET.CFG 
for the LAN driver that you are using. For example: 


Link Driver TOKEN 








The NetWare DOS Client installation program usually adds this statement 
into the NET.CFG for you. 


2. Enable all frame types for the adapter. 


Link Driver TOKEN 
FRAME TOKEN-RING MSB 
FRAME TOKEN-RING_SNAP 


3. Bind ODINSUP to the ODI driver by adding the following to the NET.CFG: 


Protocol ODINSUP 
BIND TOKEN 
BUFFERED 










































































STARTNET.BAT changes 


The STARTNET.BAT file will need to be modified so that the ODINSUP protocol 
driver is loaded and the NDIS protocol driver will bind to the ODI adapter driver. 
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The following lines need to be added to the STARTUP.BAT after the ODI adapter 
driver has loaded and before IPXODI is loaded: 


c: nwclient odinsup 
c:\net\net start netbind 
c:\net\net start netbios 


Here are the complete listings of 


the CONFIG.SYS, AUTOEXEC.BAT, 


PROTOCOL.INI, STARTNET.BAT and NET.CFG files that were used in our testing: 


CONFIG.SYS 


EVICE=C: \DOS\HIMEM. SYS 
EVICEHIGH=C: \DOS\EMM3 86 . EXE 
OS=HIGH, UMB 

EVICEHIGH=C: \DOS\SETVER. 
ES=30 
UFFERS=10 
ASTDRIVE=Z 















































H 
li 











GOrPWHUDUY 























device=C:\NET\dlshelp.sys 
rem device=c:\net\ibmtok.sys 


AUTOEXEC.BAT 


@ECHO OFF 

PROMPT Sp$g 

PATH=C: \NET;C: \NWDBPATH;C: \DOS 
P. 

Ss 








ATH=C: \NWCLIENT\ ; 3PATHS 
ET TEMP=C: \DOS 

LH C:\DOS\MOUSE.COM 

LH SHARE 
REM C:\NET\NET START 

@CALL C:\NWCLIENT\STARTNET. BAT 












































PROTOCOL.INI 


[network.setup] 
version=0x3100 
netcard=ibmS$ibmtr4a,1,IBMSIBMT. 


EVICE=C: \NET\PROTMAN.DOS /i:C: 


noems x=dc00-dfff 





i 


R4A 





transport=ibmSnetbeui, IBMSNETB 








EUL 





lana0=ibmSibmtr4a,1,ibm$netbeu 


[protman] 
DriverName=PROTMANS 
PRIORITY=ibmSNETBEUL 














[IBMSIBMTR4A] 
DriverName=IBMTOKS 











[IBMSNETBEUT ] 
DriverName=netbeuiS$ 
SESSIONS=6 

NCBS=12 

; BINDINGS=IBMSIBMTR4A 
BINDINGS=TOKEN 
LANABASE=0 

















STARTNET.BAT 


SET NWLANGUAGE=ENGLISH 
: \NWCLIENT\LSL 

: DRIVER1 
: \NWCLIENT\ TOKEN .COM 
:\nwclient\route.com 
:\nwclient\odinsup 
:\net\net start netbind 
:\net\net start netbios 
: \NWCLIENT\ IPXODI 

: \NWCLIENT\VLM 














Q 























qaqaqaaan 





i 
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NET.CFG 


Link Driver TOKEN 
PORT A20 
FRAME TOKEN-RING MSB 
FRAME TOKEN-RING_SNAP 
MAX FRAME SIZE 4208 



































Protocol ODINSUP 
BIND TOKEN 
BUFFERED 

















Implementing LANSUP 

LANSUP maintains the NDIS protocol stack configured by the LAN Support 
Program and, therefore,this coexistence method does not require much further 
configuration once the LAN Support Program has been installed. 


DOS LAN Services includes the necessary LAN Support Program files. These 
can be installed when the DOS LAN Services client is installed for IEEE 802.2. 
The LANSUP.COM driver is provided with the NetWare DOS Client. Figure 111 
on page 192 shows how LANSUP integrates the NetWare Client into an IEEE 
802.2 environment. 


Installation steps for LANSUP: These are the steps used in our test 
environment. 
1. Install DOS LAN Services configured for 802.2. 


2. Install the NetWare DOS Requester. When selecting the ODI driver to use, 
select the ODI Module for the IBM LAN Support Program. The installation 
program will then create the STARTNET.BAT file and will also create/modify 
a NET.CFG file and add the configuration parameters for the LANSUP driver. 


3. AUTOEXEC.BAT then needs to be modified. 
AUTOEXEC.BAT changes 


Prevent the DOS LAN Services client requester from starting in the 
AUTOEXEC.BAT. The reason for doing this is to avoid a problem with drive 
mappings. This problem is discussed later in “Hints and Tips” on page 201 
For example: 

rem c: net net start 


Here are the complete listings of the CONFIG.SYS, AUTOEXEC.BAT, 
PROTOCOL.INI, STARTNET.BAT and NET.CFG files that we used in our testing: 
















































































CONFIG.SYS 

DEVICE=C: \DOS\HIMEM. SYS 
DEVICEHIGH=C: \DOS\EMM386.EXE noems x=dc00-dfff 
DOS=HIGH, UMB 

DEVICEHIGH=C: \DOS\SETVER. EXE 
FILES=40 

BUFFERS=10 

LASTDRIVE=Z 

DEVICE=C: \NET\DXMAOMOD.SYS 001 
DEVICE=C: \NET\DXMCOMOD. SYS 

DEVICE=C: \NET\DXMTOMOD.SYS s=20 c=20 
DEVICE=C: \NET\DLSHELP.SYS 
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AUTOEXEC.BAT 


@ECHO OFF 

PROMPT Sp$g 

PATH=C: \NET;C: \NWDBPATH;C: \DOS; 
P. 

Ss 





ATH= C:\NWCLIENT\ ; PATHS; 
ET TEMP=C: \DOS 
LH C:\DOS\MOUSE.COM 
LH SHARE 
rem C:\NET\NET START 

@CALL C:\NWCLIENT\STARTNET. BAT 









































PROTOCOL.INI 


[network.setup] 

version=0x3100 
netcard=ibmSibmtr4a,1,IBMSIBMTR4A 
transport=ibm$netbeui, IBMSNETBEUL 
lana0=ibmSibmtr4a,1,ibm$netbeui 














[protman] 
DriverName=PROTMANS 
PRIORITY=ibm$SNETBEUL 














[IBMSIBMTR4A] 
DriverName=IBMTOK$ 











[IBMSNETBEUT ] 
DriverName=netbeui$ 
SESSIONS=20 

NCBS=20 
BINDINGS=IBMSIBMTR4A 
LANABASE=0 

















STARTNET.BAT 


SET NWLANGUAGE=ENGLISH 
C: \NWCLIENT\LSL 

: DRIVER1 
C: \NWCLIENT\LANSUP.COM 
C: \NWCLIENT\ROUTE.COM 
C: \NWCLIENT\IPXODI 

C: \NWCLIENT\VLM 




















ea 





GI 








NET.CFG 


Link Driver LANSUP 
int 2 
LINK STATIONS 1 
FRAME TOKEN-RING MSB 

















DOS LAN Services and NetWare DOS Shell Coexistence 


The NetWare Shell (NETX) intercepts all DOS interrupt requests and decides if 
the request is for a NetWare Requester or a DOS service. If the request is for a 
DOS service then it is passed on to DOS. 


In order for the NetWare shell to communicate with the NetWare server, the 
network transport layer must already be established. The network transport 
layer can be provided by using either ODI drivers or the older imbedded IPX 
network drivers (IPX.COM). The imbedded IPX drivers are no longer supported 
by Novell so only the ODI drivers will be discussed here. 


The NetWare Shell functions are provided by one of the following modules: 


NETX.EXE DOS real memory requester 
EMSNETX.EXE Expanded memory requester 
XMSNETX.EXE Extended memory requester 
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The installation procedures used for the NetWare DOS shell (NETX) were the 
same as the procedure used for installing the VLMs, but instead of loading 
VLM.EXE we load NET.EXE. NETX.EXE can be obtained from the latest DOS 
Client patch kit. At the time of writing, the latest patch kit was called DOSUP9. 





The LASTDRIVE statement in the CONFIG.SYS will also need to be changed as the 
DOS shell begins defining network drives after the drive defined by LASTDRIVE. 





























Use the following steps to implement the NetWare Shell. 


1. If implementing ODINSUP follow the installation steps provided in “ 
Installation steps for ODINSUP” on page 195. 


2. If implementing LANSUP follow the installation steps provided in “Installation 
steps for LANSUP” on page 198. 


3. Modify the CONFIG.SYS file to change the LASTDRIVE statement. The first 
drive after LASTDRIVE will be where the NetWare LOGIN program will be 
located. For example: 















































LASTDRIVE=P 
The LOGIN program will be located in the directory Q:\LOGIN. 


The NetWare Shell normally maps NetWare drives to drive letters that are 

after the drive defined by the LASTDRIVE. It is possible to map NetWare drives 
below the drive specified, but they will be considered as local drives and you 

will be prompted if you wish to remap the drive. 


4. When using the NETX shell, it does not matter if the DOS LAN Services 
requester is loaded before NETX.EXE. 

















In the case of the ODINSUP configuration, the NDIS protocol driver needs to 
bind to the ODI adapter driver before IPXODI is loaded. So in our 

configuration, we added the c: net net start command to our 
STARTNET.BAT file before the command to load IPXODI.COM. Issuing the 

net start command loads the NETBIOS support, performs the NET BIND and 
loads the requester. 


If using the LANSUP configuration, then the c: net net start command in 
the AUTOEXEC.BAT can stay as it is. 


5. Copy the NET.EXE from DOSUP9 into the NWCLIENT subdirectory. 


6. Modify the STARTNET.BAT file so that NETX.EXE is loaded instead of 
VLM.EXE. 


Here are the CONFIG.SYS, AUTOEXEC.BAT and STARTNET.BAT used in a 
ODINSUP configuration. The PROTOCOL.INI and NET.CFG files remain the same 
as in the ODINSUP configuration when using VLMs, so you can refer to the 
previous listings of those files. 


CONFIG.SYS 


EVICE=C: \DOS\HIMEM. SYS 

EVICEHIGH=C: \DOS\EMM386.EXE noems x=dc00-dfff 
OS=HIGH, UMB 
EVICEHIGH=C: \DOS\SETVER. EXE 
ILES=30 
UFFERS=10 
ASTDRIVE=P 
EVICE=C:\NET\PROTMAN.DOS /i:C:\NET 
device=C:\NET\dlshelp.sys 

rem device=c:\net\ibmtok.sys 
























































GOrPWHUOBUY 


























Inside OS/2 LAN Server 4.0 


AUTOEXEC.BAT 


@ECHO OFF 

PROMPT Sp$g 

PATH=C: \NET;C: \NWDBPATH;C: \DOS; 
P. 

Ss 





ATH= C:\NWCLIENT\ ; PATHS; 
ET TEMP=C: \DOS 
LH C:\DOS\MOUSE.COM 
LH SHARE 
rem C:\NET\NET START 

@CALL C:\NWCLIENT\STARTNET. BAT 









































STARTNET,BAT 





SET NWLANGUAGE=ENGLISH 
C:\NWCLIENT\LSL 

: DRIVER1 
: \NWCLIENT\ TOKEN .COM 
:\nwclient\route.com 
:\nwclient\odinsup 
:\net\net start 
: \NWCLIENT\ IPXODI 
: \NWCLIENT\NETX 
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Here is an example of a modified CONFIG.SYS, AUTOEXEC.BAT and 
STARTNET.BAT used in the LANSUP configuration: 


CONFIG.SYS 


EVICE=C: \DOS\HIMEM. SYS 

EVICEHIGH=C: \DOS\EMM386.EXE noems x=dc00-dfff 
OS=HIGH, UMB 
EVICEHIGH=C: \DOS\SETVER. EXE 
ILES=40 
UFFERS=10 
ASTDRIVE=P 
EVICE=C: \NET\DXMAOMOD.SYS 001 
EVICE=C : \NET\DXMCOMOD. SYS 

EVICE=C: \NET\DXMTOMOD.SYS s=20 c=20 
EVICE=C: \NET\DLSHELP. SYS 
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DUUDNDE 











AUTOEXEC.BAT 


@ECHO OFF 

PROMPT $p$g 

PATH=C: \NET;C: \NWDBPATH;C: \DOS; 
P. 

Ss 





ATH= C:\NWCLIENT\ ; PATHS; 








ET TEMP=C:\DOS 

LH C:\DOS\MOUSE.COM 
LH SHARE 

C:\NET\NET START 
@CALL C: \NWCLIENT\STARTNET. BAT 

















Ly 




















STARTNET.BAT 


SET NWLANGUAGE=ENGLISH 
C: \NWCLIENT\LSL 

: DRIVER1 
C: \NWCLIENT\LANSUP.COM 
C: \NWCLIENT\ROUTE.COM 
C: \NWCLIENT\IPXODI 

C: \NWCLIENT\NETX 






































Hints and Tips 

The general functionality and interoperability of the DOS LAN Services 4.0 client 
was not affected by the installation of NetWare DOS client software, and vice 
versa. 


The NetWare DOS Client was used to provide access to the NetWare servers and 
DOS LAN Services was used to provide access to the OS/2 LAN Server 4.0, 
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Windows NT Advanced Server, Windows For Workgroups and OS/2 LAN 
Manager. 


These are some issues to be aware of: 
Using VLMs 


In the past there have been problems when trying to run DOS LAN Services and 
VLMs concurrently. In our testing ,it was possible to have both loaded but we 
encountered a problem mapping drives to a NetWare server. 


When loading VLMs, you need to login to the NetWare server first, before 
starting the redirector part of DOS LAN Services. After loading the DOS LAN 
redirector, it was not possible to MAP drives to a NetWare server. Therefore, if 
you try to login to the NetWare server with the DOS LAN Services redirector 
already loaded, the drive mappings contained in the login scripts will fail. 


An example of an error message when attempting to login: 





LOGIN-4.084-470: The specified drive mapping is an invalid path: 
(SYS :HOME/ADMIN) 




















An example error message when trying to MAP a drive: 

















MAP-4.071-195: Directory [SYS:PUBLIC] cannot be located. 


So after logging into the NetWare server with required drive mappings complete, 
the NET START command can be ran. 





This problem does not occur with the NETX shell. 





If you try to do a NET USE to a drive that has already been assigned by the 
NetWare MAP command then the command will fail with an error. For example: 














Error 85: The local device name is already in use. 
Using NETX 


It is possible to login to the NetWare 4.x server with the NETX shell using bindery 
emulation. Some NetWare 4.x utilities do not work or do not work the same as 
when using the VLM DOS Requester. 


When using the NETX shell, it was possible to MAP a drive that had already been 
assigned with the NET USE command. Running the NET USE command again with 
no parameters shows the drive as the original LAN Server assignment, when in 
fact the drive is now mapped to a NetWare server. Performing a DIR on that 
drive will show you a directory listing on the NetWare server. Issuing the MAP 
EL on that drive will revert it back to it's original path assigned by the NET USE 
command. 
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Using LAN Server as an Interoperability Gateway 


It is possible to use LAN Server as a type of gateway to other servers, thereby 
providing seamless interoperability for your users. Although this concept is not 
new to LAN Server 4.0, with stronger interoperability support in this release, it 
becomes more of an issue. 


The following figure shows a LAN Server with the NetWare for OS/2 client and 
TCP/IP for OS/2 installed. This allows an administrator logged on at that 
workstation to access resources on a NetWare server and an AIX server 
(assuming valid user IDs on both), and then share those resources as LAN 
Server resources. 
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with NetWare for OS/2 Client and TCP/IP for OS/2 


me 









































= 
TUNE 
emul J 
eL_ts 


NetWare 3.12 Server AIX Server 


LJ |_| 


=a 
eS 
































































































From the LAN Server, an administrator can access resources on 
NetWare and AIX servers, and then share those resources 
as LAN Server resources for other clients to access. 
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Figure 112. LAN Server as an Interoperability Gateway 


Because LAN Server is not a dedicated server, it can also be a client to other 
server types. From a workstation that is running LAN Server software (that is, 
sharing its resources with requesters), you can also be a client to NetWare 
servers, NTAS servers, AIX servers, and so on. To do this may require installing 
additional software, such as the NetWare for OS/2 Client or TCP/IP for OS/2. To 
access Microsoft servers, however, additional software is not needed, as we 
have explained in this chapter. 


Once you have connected to another server's resource from your LAN Server 
workstation, you can then share that resource as a LAN Server resource. That 
is, users at LAN Requesters, DLS workstations, and even Microsoft workstations 
(such as Windows for Workgroups) can access that resource as if it were a LAN 
Server resource. 
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For example, from your LAN Server workstation where you have installed the 
NetWare for OS/2 client, you can issue a NetWare MAP command to access a 
NetWare directory as your drive N:. Then, you can share your drive N: as if it 
were local, through either the GUI or the NET SHARE command, as follows: 





NET SHARE NWDIR=N: 

















Now you have a netname called NWDIR, which really points to the NetWare 
server. You could even set up an alias for this resource. Users can access this 
resource, and to them it looks like a directory on the LAN Server workstation. 


Why would you want to do this? Perhaps one or more of your users need 
occasional access to a resource, such as an expensive printer, on a different 
server type on the network. Especially if this would ordinarily involve installing 
additional software on the client and requiring the user to learn new commands, 
as would be the case for accessing a NetWare or AIX server, you could consider 
the use of LAN Server as a gateway to that other server. 


However, it is important to be aware of the license purchased for the server you 
are accessing and to adhere to the license agreement. If your users need 
continuous access to the server, it may be best to go ahead and install the 
necessary client software on that user's machine. 


Inside OS/2 LAN Server 4.0 





Chapter 10. High Performance File System 386 


The High Performance File System 386 (HPFS386) is highly optimized and 
designed for 80386SX and higher-based platforms with large disk systems. The 
HPFS386 provides extremely fast access to large disk volumes and optimizes 
performance in a server environment where many files are open simultaneously. 
The HPFS386 is an enhancement of the regular HPFS that is part of OS/2. It 
represents the logical evolution of LAN Server technology. The server consists 
of an optimized Ring 0 server tightly coupled with a bootable Installable File 
System (IFS) and customized device drivers to accelerate network I/O. 


The 386-specific version of the HPFS is disk-format-compatible with the OS/2 
Standard Edition version. The existing HPFS partitions do not require 
reformatting when HPFS386 is installed. 


With the LAN Server 4.0 HPFS386, you can now set DASD limits on directories. If 
you set a limit on a shared server directory, your users cannot increase the size 

of the directory past that limit, even if the physical disk space is not full. In 
addition, you can specify that alerts be generated to users or groups when 

certain thresholds are met. There are new parameters for HPFS386 (in the 
HPFS386.INI file) that allow you do use the DASD limit feature. 





Functional Description 


© Copyright IBM Corp. 1995 


The HPFS386 is heavily cached and uses intelligent read-ahead and write-behind 
logic, while the server architecture permits network transfer of partially 

completed requests. The server system consists of the 386 SMB (Server 
Message Block) server and the HPFS386. The performance of the components is 
enhanced by the disk and network drivers, completing the server environment by 
providing top to bottom paths with no performance bottlenecks. A simplified 

model of how these parts cooperate in the OS/2 environment is shown in 

Figure 113 on page 206. 
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Figure 113. 386 SMB Server System Architecture 


Examples of paths traced through the system are given below: 
Local access to HPFS file in HPFS386 cache: f - g 
Local access to HPFS file, not in cache: f - g - i 
Local access to FAT file: f - h 
Network access to HPFS file, in HPFS386 cache: a-b-c 
Network access to HPFS file, not in HPFS386 cache: a-b-c-i 
Network access to FAT file: a- b-d-e-h 
When a Server Message Block (SMB) is received by the network adapter 


hardware at the server, the request is passed through the Media Access Control 
(MAC) driver and transported to the SMB server. 


If the request is for HPFS386, the server calls the file system directly. If the 
request can be satisfied without disk I/O (such as a read of data in the file 
system cache), a response to the request may be sent in the context of servicing 
the original network interrupt. If the request requires disk I/O, the request is 
queued directly to the disk driver, which sorts requests for optimal service and 
notifies the server when the request is satisfied. 


In servicing requests such as the ones described above, the following 
optimization results from the tightly coupled structure of the system: 


All components from the Network Driver Interface Specification (NDIS) driver 
to the file system share a common buffer pool, minimizing the need to copy 
data. 
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Extensions to the disk driver interface allow data to be transferred to and 
from the disk using the same buffer utilized in network I/O. 


+ All components run at Ring 0, eliminating delays caused by sending 
transitions to a Ring 3 server (LANSRV). 


This architecture adds up to an extremely efficient network kernel, providing 
pipelined access to HPFS files. 


Since LAN Server 3.0, the cache memory area can be expanded beyond 16MB. 
This is particularly effective in improving the server performance if the hardware 
allows vast amounts of memory such as 32MB or 64MB. It is true large cache 
memory reduces physical disk I/Os in most cases and increases the system 
performance. However, you need a 32-bit DMA(Direct Memory Access) capable 
LAN adapter to use this feature, although IBM Token-Ring Network 16/4 
Adapter/A can work with the large cache area beyond 16MB. Details are 
discussed in “LAN Adapter Considerations for more than 16MB Memory” on 
page 208. 





HPFS386 Terms 


It is necessary to define some terms that will be used in the following description 
of HPFS386: 


Cache Hit This defines the situation when a file read request is satisfied by 
reading from the cache, without reading from the disk. 


Dirty This defines a cache block that contains data that is different 
from what is actually on disk. For example, a cache block has 
been updated with a write request, but has not been written 
physically to the disk. 


Flush This means writing cache contents to the disk. 


Hot Fix When a bad sector is found, the file system automatically 
allocates a new sector for it, and reroutes future requests for the 
bad sector to the good sector. 


Idle This is a cache block that is not being read from or written to. 


Touch This means accessing (read or write) a cache block. 





HPFS386 Components and Features 


All features of HPFS are supported by HPFS386. Features marked with an # in 
the following list are exclusive to HPFS386. All other are common to the OS/2 
and 386 versions of the HPFS. Features marked with ## are new in HPFS386 
since LAN Server 3.0. 


* # 80386-specific, 32-bit code 
Extended attribute support 
+ File names up to 254 characters 
Strategic allocation of directory structures 
Highly contiguous file allocation 
Caching of directories, data, and file system structures 


Use of file-access-based heuristics 
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Multi-threaded I/O 
Read-ahead and lazy-write processes 
* Optional write-through 
+ Ability to boot an operating system 
+ Enhanced recoverability 
* Hotfix defect mapping 
* # Access and audit control in the file system 
* # Local security 
+ # Support for fault-tolerant, enhanced disk drivers 
+ # Support fixed disks greater than 4GB in size 
+ # Support for files up to 2GB in size 
+ # Tight coupling to the 386 SMB server 


+ # With HPFS386, a directory's time stamp will change anytime one of the 
following happens: 


- A file is created within it 

- One of its files is modified 

- One of its files is deleted 

- A subdirectory is created within it 
- One of its subdirectories is deleted 


+ ## Increased number of open files limit to 64K, searches to 6K and finds to 
8K 


+ ## Support for adapter card memory greater than 16MB in size 
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Because OS/2 2.0 and higher allows access to greater than 16MB of memory, 
HPFS386 is capable of using more memory for its cache. Its performance is 
greatly improved by allowing access to memory beyond 16MB. However, some 
restrictions exist in dealing with LAN adapters and device drivers that are not 
capable of addressing memory above 16MB. 


A switch has been added to the HPFS386.INI file that indicates whether the file 
system can attempt to exploit memory above 16MB. The name of this switch is 
/USEALLMEM. The presence of this switch indicates to HPFS386 that it should 
attempt to exploit memory above 16MB as much as possible. Refer to 
Figure 115 on page 211 for details on how this new parameter works. 


There are typically three types of LAN adapters from the data transfer between 
PC memory and adapter point of view: 
Shared RAM adapter 
* 24-bit DMA adapter 
* 32-bit DMA adapter 


IBM Token-Ring Network 16/4 Adapter/A is the typical shared-RAM adapter. The 
device drivers IBMTOK.OS2 and NETBEUI.OS2 can handle the data moving 
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between the shared-RAM area and the protected-mode cache area above 16MB. 
Even though the data movement is required, the large cache can be supported. 
An example of a LAN adapter/device driver which is 24-bit DMA and cannot 
address beyond 16MB is the IBM Token-Ring Busmaster Adapter (F/C 4041 P/N 
74F 4140) and its device driver IBMTRBM.OS2. An example of a 32-bit DMA 
adapter is the IBM LANStreamer MC 32 Token-Ring Adapter, and its device 
driver IBMTRDB.OS2. 
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Figure 114. Consideration - Common Cache Area Beyond 16MB 
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HPFS386 Installation 


HPFS386 can be installed on any machine capable of running OS/2 2.0 or higher. 
The advanced HPFS386 function is automatically selected to install if there is at 
least one HPFS partition on your hard disks. During installation, you can specify 
the size of the cache as well as the size of the heap (internal area for HPFS386 
structures). The default value is recommended, unless you have some other 
special reason to change it. 


HPFS386 Parameters 
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With LAN Server 3.0 Advanced, after the installation, you have the following 
statement with its parameters in the CONFIG.SYS file: 


IFS=d: IBM386FS HPFS386.IFS d: IBM386FS HPFS200.386 
/I:d:\IBMLAN /A:* 






































After the LAN Server 4.0 Advanced installation, you have the following statement 
in the CONFIG.SYS file: 


IFS=d: IBM386FS HPFS386.IFS /A:* 

















The HPFS 386-related parameters are now in the IBM386FS directory in the 
HPFS386.INI file. 


Figure 115 on page 211 describes the HPFS 386-related parameters. 
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; This file contains the initialization parameters for the 386 HPFS. The 
; Parameters are grouped into components. The component groups start with the 
component name enclosed in square brackets. Each component name appears on 





; a line by itself (a comment is allowed). The components include the 
; following: 

; [filesystem] ; General file system parameters 

; [lazywriter] ; Lazy writer parameters 

; [DASD_Limits] ; DASD Limits parameters 


General rules: 
- The component names and parameters are not case-sensitive. They can be 
entered in upper case, lower case, or a mixture of upper and lower case. 
; - Wherever a blank appears in the syntax for a parameter, it can be left out 
or additional blanks can be added. For example, the following syntaxes 
are all valid: 
cachesize = 4096 
F cachesize = 4096 
; cachesize = 4096 
; - Any text after a semicolon (;) up to the end of the line is treated asa 
; comment. 
; - All components and parameters are optional. If you do not specify a 
; parameter, the 386 HPFS uses a default setting for the parameter. 


; The [filesystem] section specifies general file system parameters. If you 
; make any changes to these parameters, they do not take effect until you 
; reboot the system. 


; useallmem = [yes|no] 

; This parameter specifies whether the 386 HPFS should use memory above the 
: 16M boundary, provided this system is configured with more than 16M. 

; Some adapters, for example the IBM Token Ring Busmaster Server/A, cannot 
- do direct memory access (DMA) to memory above the 16M boundary. If you 

; have a LAN or disk adapter that cannot do DMA to memory above the 16M 

; boundary, the 386 HPFS must use only memory below 16M so that the adapter 
; can put data into the file system buffers. Set useallmem to yes if all 

; of your adapters can access memory above the 16M boundary. Set useallmem 
> to no if any of your LAN or disk adapters cannot access memory above the 

; 16M boundary. If useallmem is not specified, the default setting is no. 


; cCachesize = nnnn 

; This parameter specifies how many kilobytes of memory the 386 HPFS should 
; claim for its cache. The cache size must be a minimum of 256KB. The 

; maximum value is determined by the size of available memory. If 

; cachesize is not specified, the default is to use 20% of available 

; memory, if the amount of available memory is below 20MB, or 60% of 

; available memory, if the amount of available memory is 20MB or more. 


; maxheap = nnnn 

; This parameter sets a limit on the size of the heap. nnnn is the maximum 
; number of kilobytes to which the heap can grow. The 386 HPFS allocates 

- heap memory as needed. If this parameter is used, the 386 HPFS only 

; allocates memory for the heap up to the amount specified. If this 
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parameter is not used, there is no limit on the heap size. Use this 
parameter only if you need to reserve memory on the system for other 

; applications that may be running. The minimum value is 64KB. The 

; maximum value is determined by the size of available memory minus the 

; size of the cache. If maxheap is not specified, the default is to have 
} no limit on the heap size. 


; Lanroot = d:\path 

: This parameter specifies the drive and path of the directory for the LAN 
; Server software. The installation program fills in this parameter for 

Fi you. You do not need to change this parameter. 


; £sprealloc = nn 

} This parameter specifies how many big buffers to allocate when the file 

: system is initialized. If neither fsprealloc nor srvprealloc are used, 

; the file system allocates big buffers as needed. The allocation of big 

; buffers can take a little time. Allocating the big buffers at 

; initialization improves the performance of the first requests that need 

; big buffers. The buffers are not freed until the system is shut down. 

: The minimum value for fsprealloc is 2. The maximum is 64. If both 

; fsprealloc and srvprealloc are specified in this file, fsprealloc is used 
; and srvprealloc is ignored. 


; srvprealloc = nn 

; This parameter specifies how many big buffers to allocate when the server 
7 is started rather than when the file system is initialized. This 

F, parameter, like the fsprealloc parameter, can improve the performance of 
. the first requests that need big buffers. The buffers are freed when 

: the server is stopped. The minimum value for srvprealloc is 2. The 

; maximum is 64. If both fsprealloc and srvprealloc are specified in this 
; file, fsprealloc is used and srvprealloc is ignored. 





[filesystem] 
useallmem = NO 
lanroot = C:\IBMLAN 


; The [lazywriter] section specifies settings for the lazy writer. If you 

; make any changes to these parameters, they do not take effect until you 

; reboot the system. You can use the CACHE386 program to change the internal 
; setting of these parameters while the system is running. When you reboot 

; the system, the parameters are set to the values in this file. 





; lazy = [drives:] onloff 

; This parameter specifies whether the lazy writer is to be turned on or 
; off for the specified drives. The [drives:] can be a series of drive 
: letters. For example, "lazy = cdfg: on" would turn on the lazy writer 


; on drives c:, d:, f£:, and g:. It would not change the 
: settings for drive 
7 e: or h:. An asterisk (*) can be used for the drive letter to indicate 


; that all drives are to have the setting. This line can be used multiple 
; times to achieve the settings you want for your drives. If lazy is not 
; specified, the default value is to turn the lazy writer off for all 

: drives. 
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maxage = [drives:] nnnn 

This parameter specifies the maximum number of milliseconds that can pass 
;: before the lazy writer writes the contents of a buffer to the disk. The 

; drives:] can be a series of drive letters. For example, 

; "maxage = cdfg: 5000" would set the maximum buffer age to 5000ms on 


i 
i 


: drives c:, d:, f£:, andg:. It would not change the settings 
2 for drive e: 
or h:. An asterisk (*) can be used for the drive letter to indicate that 


: all drives are to have the setting. This line can be used multiple times 
H to achieve the settings you want for your drives. The minimum value is 

; 0. The maximum value is 1000000. If maxage is not specified, the 

; default value is 10000 for all drives. 





; bufferidle = [drives:] nnnn 

; This parameter specifies the maximum number of milliseconds during which 
; a buffer is not used before the lazy writer writes the buffer contents to 
; the disk. The [drives:] can be a series of drive letters. For 


example, 
; "bufferidle = cdfg: 500" would set the buffer idle time to 500ms on 
; drives c:, d:, f£:, andg:. It would not change the settings 
; for drive e: 
; or h:. An asterisk (*) can be used for the drive letter to indicate that 


: all drives are to have the setting. This line can be used multiple times 
; to achieve the settings you want for your drives. The minimum value is 

; 0. The maximum value is 500000. If bufferidle is not specified, the 

?. default value is 1000 for all drives. 


[lazywriter] 
lazy = *; ON 
maxage = *: 5000 


bufferidle = *: 500 


; The [DASD_Limits] section specifies settings of parameters for the DASD 

; Limits function. If you make any changes to these parameters they do not 

; take effect until you restart the server. (To stop and restart the server, 
; at an OS/2 command prompt, enter the command "net stop server" and then the 
; command "net start server".) 


; ThreshAlertNames = [drives:] [user1] 
[user2] [group1] [group2]... 

; This parameter lists the users or groups that are to be notified when a 

: DASD Limits threshold is crossed on the specified drives. Any mixture of 
; user names or group names can be used. All of the names must appear on 

; one line. This line can be used multiple times to achieve the settings 

; you want for your drives. If ThreshAlertNames is not specified, the 
default is to have no user or group names. 


ThreshAlertDelay = [drives:] nn 

; This parameter specifies how many minutes to wait before sending another 
; alert for a threshold that was previously crossed on the specified 

: drives. If a threshold is crossed more than once within the delay 

: period, an alert is sent only for the first occurrence. An alert is sent 
; if a higher threshold is crossed during the delay period. This parameter 
; is used to cut down on the number of alerts that can be generated when 








Figure 115 (Part 3 of 4). HPFS386.INI File 


Chapter 10. High Performance File System 386 213 





there is a lot of disk activity and the disk size is within the 
threshold. This line can be used multiple times to achieve the settings 
; you want for your drives. If ThreshAlertDelay is not specified, the 

¢ default is 10 minutes on all drives. 


; ThreshAlertUser = [drives:] yes|no 

This parameter specifies whether to send an alert to the user whose disk 
; usage caused a threshold to be crossed on the specified drives. This 

: line can be used multiple times to achieve the settings you want for your 
; drives. If ThreshAlertUser is not specified, the default is yes for all 
; drives. 


; DirFullAlertNames = [drives:] [user1] 

; {user2] [user3]... 

; This parameter lists the users or groups that are to be notified when a 
: DASD limit is reached. Any mixture of user names or group names can be 
; used. All of the names must appear on one line. This line can be used 
; multiple times to achieve the settings you want for your drives. If 

: DirFullAlertNames is not specified, the default is to have no user or 

; group names. 


; DirFullAlertDelay = [drives:] nn 

; This parameter specifies how many minutes to wait before sending another 
; alert for a DASD limit that was previously reached. If a DASD limit is 

; reached more than once within the delay period, an alert is sent only for 
; the first occurrence. This parameter is used to cut down on the number 

; of alerts that can be generated when there is a lot of disk activity and 
: the DASD limit is reached several times. This line can be used multiple 
; times to achieve the settings you want for your drives. If 

; DirFullAlertNelay is not specified, the default is 10 minutes on all 

; drives. 


; DirFullAlertUser = [drives:] yes|no 

: This parameter specifies whether to send an alert to the user whose 

: request failed because a DASD limit was reached. This line can be used 
; multiple times to achieve the settings you want for your drives. If 

; DirFullAlertUser is not specified, the default is yes for all drives. 





[DASD_Limits] 
ThreshAlertNames = *: ADMINS 
ThreshAlertDelay = *: 10 
ThreshAlertUser = *: yes 
DirFullAlertNames = *: ADMINS 
DirFullAlertDelay = *: 10 
DirFullAlertUser = *: yes 











Figure 115 (Part 4 of 4). HPFS386.INI File 


214 inside OS/2 LAN Server 4.0 


Access Control List (ACL) 


The access control structure in LAN Server 4.0 is the same as in LAN Server 3.0. 
However, we have chosen to include this information describing the basics of 
ACLs. 


In the FAT file system and in the HPFS of LAN Server 4.0 Entry, the access 
control information is stored in the file NET.ACC. In the HPFS386, the access 
control list is stored as a part of the file system. This means: 


Every file or directory on an HPFS volume is anchored on a fundamental file 
system object called Fnode. The Fnode is the fundamental object in an HPFS 
volume and is the first sector allocated to a file or directory. 


Each Fnode contains control and access history information used internally 
by the file system. 


* The Fnode contains an allocation information for the access control list. 


The access control list consists of different entries, called Access Control Entries 
(ACE). For every access restriction of a userlID, you can find an entry. The entry 
consists of the userlD or the groupID and the permission. The entries are 
created when an access profile is created for a special file or directory. Each 
ACE is sometimes called as Access Control Profile (ACP). 


The user interface to handle the access control information is unique to 386 
HPFS. The special interface is provided to create, delete and grant the access 
permissions for a particular userlD to the directory or the file. The interfaces are: 


LAN Requester GUI 
- NET ACCESS command 


* APIs such as NetAccessAdd, and others 


Whenever a directory is created, inheritance always takes place. That means if 
its parent directory has an ACL, the new directory will have the same ACL. In 
case of disk corruption and booting with a standard OS/2 boot diskette, you do 
not have the access to files which have these new Fnodes. Therefore, it is 
necessary to create a HPFS386 boot diskette to make the files visible and 
accessible in case that diskette boot is required. 





-— Warning 


When copying of a directory structure from a non-HPFS386 server to a 386 
HPFS server (or vice versa), the access control profiles will not be copied 
automatically. After this type of data movement, the administrator should 
create the required access control profile. 











The following figure shows the structure of an Fnode and how the ACLs are 
copied with the regular backup/restore utility, such as the new versions of Sytos 
Plus product. The OS/2 backup command does not copy the ACLs; it copies only 
the extended attribute and the file data area of an Fnode. 
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Figure 116. HPFS386 ACL 





HPFS386 Boot Diskettes 
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If you install the HPFS386, you must create HPFS386 boot diskettes to use in the 
event the fixed disk fails to start the workstation in the future. A regular HPFS 
boot diskette, such as an OS/2 2.X installation diskette, cannot access files or 
directories with access control profiles. 


Create HPFS386 boot diskettes after installing the OS/2 base operating system 
and LAN Server 4.0 on a workstation. Keep a unique set of these diskettes for 
each workstation that uses the HPFS386 file system. You can use these diskettes 
if it is necessary to start the workstation without using the operating system 
partition of the hard disk. 


Do not use your original OS/2 installation diskettes for this purpose. Always work 
with backup copies of your original diskettes. The following diskettes are 
required: 


* A copy of the diskette labeled OS/2 Installation 
* A copy of the diskette labeled OS/2 Installation/Diskette 1 
The copy of the OS/2 Installation diskette is used as it is. Use the MAKEDISK 


utility to change the copy of the OS/2 Installation/Diskette 1 diskette so that the 
diskette supports HPFS386. The MAKEDISK utility alters certain files and deletes 
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others to make room for the HPFS386 system-related files. Then it copies the 
disk device drivers and HPFS386 system files from the operating system partition 
on the workstation's hard disk. 


If Fault Tolerance is activated at the workstation where you use the diskettes, 
you must run the MAKEDISK utility at that same workstation. The MAKEDISK 
utility copies the workstation's Fault Tolerance configuration files to the copy of 
the OS/2 Installation/Diskette 1 diskette. Fault Tolerance errors might occur if 
there is a difference between the workstation's Fault Tolerance configuration and 
the configuration on the HPFS386 operating system diskettes. 


Whenever you change or deactivate the Fault Tolerance system on a 
workstation, type MAKEDISK /FT to update the copy of the OS/2 
Installation/Diskette 1 diskette. This ensures that the Fault Tolerance 
configuration on the diskette is correct. 

















The following steps show you how to create the HPFS386 diskettes: 


1. Make backup copies of your original operating system diskettes labeled OS/2 
Installation and OS/2 Installation/Diskette 1. 


2. Label the copy of the OS/2 Installation diskette and set it aside. It does not 
need to be changed. 


3. Insert the copy of the OS/2 Installation/Diskette 1 diskette in drive A; then 
type the following command at the OS/2 command prompt and press Enter: 





MAKEDISK /BOOTDRIVE:C 


























This procedure uses diskette drive A, but you can use either drive A or drive 
B. The system displays a prompt asking whether the diskette is created in 
drive A or B. 


4. Select the drive that contains the copy of the OS/2 Installation/Diskette 1 
diskette and press Enter. 


5. When the MAKEDISK utility has finished, and you have finished making any 
necessary manual changes, remove the copy of the OS/2 
Installation/Diskette 1 diskette from the drive and label it. Make a note of 
which workstation you used to create the diskette. Use the diskette only at 
that workstation. 


The following steps show you how to verify the set of HPFS386 operating system 
diskettes that you made: 


1. Select Shut down from the system menu on the workstation where you 
created the diskettes. 


2. Insert the copy of the OS/2 Installation diskette and press Ctrl+Alt+Del to 
start the workstation. 


3. When prompted, insert the copy of the OS/2 Installation/Diskette 1 diskette 
that you made for this workstation. 


If you have local security installed, verify that the operating system diskettes 
can validate an administrator ID by typing an administrator ID and password 
when you are prompted to log on when the system starts. If you are not 
prompted to log on when the system starts, a problem exists with the copy of 
the OS/2 Installation/Diskette 1 diskette, and an administrator will not be 

able to log on and administer files from the command line. 


4. If the workstation starts successfully, store the diskettes for future use. 
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The HPFS386 operating system diskettes do not start the Presentation Manager 
interface, so if you use them to start the workstation, you cannot run the 
Presentation Manager system editor. To correct a damaged system file on the 
hard disk (for example, CONFIG.SYS), copy the file to a diskette, edit the file at 
another workstation, and then copy it back to the workstation's hard disk. 


Limiting DASD Space within HPFS386 Directories 


This section discusses directory limits, or disk space allocation, for use with the 
HPFS386 Advanced Server. Directory limits provide management of disk space at 
the directory level on servers. The privileged user can apply a Imit to a directory 
tree so that the size of the tree cannot grow past the imposed limit. 


The allocation scheme works in the same way as the partition of a logical drive. 
When a directory tree is full, no unprivileged user can append data to its files or 
create subdirectories within the tree. For example, a limit of 10O0MB applied to 
the C: IBMLAN directory allows only those requests for disk space that do not 
cause the usage count to exceed 100MB. You can also use a notification 
function to set up alerts to notify selected users when a directory tree is either 
full or is nearing its maximum capacity. 


Note: The information in this section is taken from the LAN Server Network 
Administrator Reference Volume 3: Network Administrator Tasks. 


Definition of Terms 


It is necessary to define some terms that are used in the following description of 
limiting disk space: 


Term Definition 


Available Space The amount of free disk space within a particular directory 
tree. The available space is the limit minus the usage 
count. However, the available space for a directory tree 
can be affected by limits placed above the directory itself. 
Consider this example: 


Root directory C: has a limit of 250MB. Its usage 
count is 200MB. 


Directory C: IBMLAN has a limit of 100MB. Its usage 
count is 20MB. 


+ The available space for the root directory is 50MB, 
which is also the available space for the C: IBMLAN 
directory because C: is in the same path as 
C: IBMLAN. Without the limit on C: , the available 
space at C: IBMLAN is either 80MB or the free space 
of the drive, whichever is less. 


Drive A logical drive, used interchangeably with "volume". 


Limit A value, in kilobytes (KB), used to control the size of a 
directory tree. 


Threshold alert An alert generated when the size of a limited directory 
increases past a size threshold, a set percentage of the 
directory limit. 
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Threshold delay The minimum amount of set time that must elapse before 
the crossing of the same or lower threshold (percentage of 
limit) can generate another threshold alert. 


Unprivileged user A user on whom directory limits are imposed. 
Usage count The current size of the directory tree as specified in KB. 


Volume A logical drive, used interchangeably with drive. 


How Directory Limits Work 


You apply directory limits only to directories, not to files. The limit you set on a 
directory applies to all users who have access to that directory. No distinction is 
made between users. 


By combining directory limits with access control lists (ACLs) of LAN Server, you 
can control both the access to a directory and the size of that directory. For 
example, you can give the user, LISA, Read (R), Write (W), Create (C), or Delete 
(D) access to the C: IBMLAN USERS LISA directory and a limit of 20MB for her 
own use. 


Directory limits are part of the HPFS386 high-performance file system. You can 
enable this function or disable it from any HPFS386 drive. 


Note: Previous versions of HPFS386 and HPFS.IFS cannot access drives that 
have directory limits enabled on them. You must create a new HPFS386 boot 
diskette, using the MAKEDISK utility. 


-—— DASD Limit Required Fixes 





If you plan to manage directory limits on the server, you must apply the 
appropriate OS/2 FIXPAKS. These are: 


OS/2 V2.1: PJ10428 
OS/2 V2.11: PJ13619 
OS/2 Warp V3: No FIXPAK required for DASD limits. 


Contact your IBM dealer representative or your service and support group for 
information on ordering these FIXPAKS. 


If you invoke Manage limits and have not installed a required FIXPAK, you 
will be informed that you should do so. 











The following rules apply to directory limits: 
* You can apply limits only to directories, not to files. 


Limits are hierarchical. A limit on a directory controls the entire sub-tree 
below the directory itself. For example, a limit on the root directory controls 
the whole drive. 


* You can place multiple limits within a path. For example, you can place a 
limit at the root directory and another at the C: IBMLAN directory. 


Limits are independent of each other. For example, you can set a limit of 10OOMB 
at the root and another limit of 120MB at the C: IBMLAN directory. LAN Server 
uses these limits when a request for disk space is received. For a request to be 
granted, it must satisfy all the limits placed within its path. In this example, a 
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request for space in the C: IBMLAN directory must satisfy both the 120MB limit 
and the 100MB limit. 
Limits are not enforced for privileged processes. Privileged processes are: 


* All processes (local and from requesters) initiated by an administrator. That 
is, administrators are not subject to limits. 


+ Privileged local processes when local security is installed. 
* All local processes when local security is not installed. 


Note: This includes access from Macintosh clients, because that access is 
viewed as local by LAN Server. For more information, see Appendix D, 
“Macintosh Client Support” on page 453. 


Tasks of Users and Administrators 


Users who are also administrators can modify directory limits at will. 


Users who are not administrators can manage the limit of a directory if they are 
given P permission on the parent of the target directory itself. For example, 
assume that user ID LISA has all permissions (including P permission) on the 
C: IBMLAN USERS LISA directory. LISA can create the directory 

C: IBMLAN USERS LISA PUBLIC and apply a limit of 15MB to it. However, she 
cannot modify the limit placed on directory C: IBMLAN USERS LISA directory 
unless she has P permission for the C: IBMLAN USERS directory. 


Consider the following scenario: 


The administrator creates a home directory for user ID JANE and gives JANE the 
access control permissions RWCDXAP. With these permissions, JANE can 
control access by other user IDs to her home directory. 


The administrator also sets a limit of 10O0MB on the home directory. JANE can 
now administer her home directory for access control and disk usage. JANE 
creates a directory called PUBLIC within her home directory, applies a limit of 
20MB to it, and, using the following command, gives unrestricted access to all 
user IDs: 








NET ACCESS homedir PUBLIC /ADD GUESTS :RWCDAX 
































where homedir is the user's home directory. 


However, Jane cannot modify the limit (100MB) applied to the root of her home 
directory. 


What Disk Space Includes 
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Disk space includes all space required to store data on disk. Each directory 
requires disk space for both the data stored within the directory and the 
file-system instructions that manage the data. For example, creating a new 
directory uses 2560 bytes because that much disk space is required to maintain 
a directory object. Even an empty file (zero bytes) uses 512 bytes of disk space. 
If a directory has 10MB of free disk space, you cannot store a 10MB file in that 
directory because the system requires extra space for directory management. 
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In rare conditions, HPFS386 does not account for certain file-system structures. 
These exceptions help HPFS386 to maintain high performance and have minimal 
effect on the accounting mechanism. 


In certain cases, HPFS386 allows a limit to be exceeded. This exception occurs 
only when the directory has room for the data that must be written to disk but 
not for the required file-system structures. For example, consider a directory with 
1024 bytes remaining. A write request of 1024 bytes is made. However, the disk 
is so fragmented that a file-system structure requiring 512 bytes is needed to 
manage the data written to disk. In this example, HPFS386 allows the request to 
continue and updates the usage count of the directory to reflect the overflow. 
HPFS386 denies subsequent requests for disk space. 


Enabling Directory Limits on an HPFS386 Volume 


Directory limits, by default, are not activated on a particular volume. You can 
enable this function on a drive from the LAN Server Administration GUI, the 
command line with the NET DASD command, from the desktop, or the 
NetDASDCtl() application programming interface (API). However, before using 
either method, be aware of the following: 


+ When you issue the ENABLE command, HPFS386 first calculates the size of 
each directory in the tree. To accomplish this, HPFS386 processes the entire 
directory tree and the files contained within it. 


If you are attempting to enable directory limits on the boot drive, the process 
only partially completes. The HPFS386 is not able to lock the drive because 
OS/2 always keeps certain files open. This failure also can occur on other 
drives that have open files. A shutdown of your system, followed by a reboot, 
completes the activation process. 


« If CHKDSK repairs a drive on which directory limits are active, HPFS386 
recalculates the size of each directory. This action is necessary because 
CHKDSK, as part of its repair operation, moves files and directories. For 
example, it creates FOUND.000 and DIROOO0O.CHK. 


Drives on which directory limits are enabled are inaccessible to HPFS.IFS 
and earlier versions of HPFS386 (for example, LAN Server 2.0 and 3.0). You 
must create a new bootable HPFS386 diskette if you choose to use this 
function. Otherwise, you cannot access these volumes when booting from a 
diskette. 


Alerts for Directory Limits 
When limits are set on the size of a directory or tree, the user of that directory 
cannot exceed the limit. Therefore, you should notify the appropriate people, not 
only when the directory is full but as it increases to the point (threshold), that it 
might not hold the necessary files. 


After the threshold is reached, the directory can decrease or increase in size 
over an unpredictable time span. Administrators and other users appreciate 

being alerted on a timely basis as the directory approaches and crosses the 
threshold. 
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Threshold Alerts 


Threshold alerts are posted when one percentage threshold is reached as the 
disk space for the directory increases within the set limit. Figure 117 illustrates 
the threshold, the limit, and their relationship to directory size. 





Limit 
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Figure 117. Threshold Alerts 


As the size of the directory increases, it crosses the threshold (1) and generates 
an alert. You can divide the threshold into incremental thresholds, which, as they 
are crossed, post additional threshold alerts. 


The ThreshAlertDelay parameter in the HPFS386.INI file defines the threshold 
delay, which is the minimum amount of time that must elapse before another 
crossing of the same or lesser threshold generates an alert (2 and 6). (The same 
threshold or a lesser one can be crossed when the size of the directory 
decreases.) The threshold delay is overridden when the directory size crosses a 
higher threshold (3 and 4). 


Directory-Full Alerts 
Directory-full alerts are posted when a directory tree is full. Figure 118 on 
page 223 illustrates the relationship between alerts, directory limits, and 
directory sizes. 
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Figure 118. Directory-Full Alerts 


Because the user cannot cross the directory limit, Directory-full alerts are 
generated only when a Directory-full condition is reached. A Directory-full 
condition occurs when a write request is denied because of insufficient space 
within the directory tree. Like threshold alerts, directory-full alerts have a delay 
window that allows you to control alert notification. The delay is provided by the 
DirFullAlertDelay parameter in the HPFS386.INI file, which defines the minimum 
amount of time that must elapse before another Directory-full condition 
generates an alert (2 and 3). The delay prevents alerts from being generated in 
quick succession when the directory space rapidly fluctuates between the limit 
and a lower value. 


Two Stages of Setting Alerts 


You set up alerts in two stages: 


Make directory-specific settings for alerts. You make these settings for the 
threshold value and the incremental threshold values. These settings apply 
only to the directory you specify. 


Make volume-wide settings for alerts. Make these settings in the HPFS386.INI 
file. Parameter values control the following variables: 


- Who receives alerts 
- Whether the user who caused the alert receives it 


- Delay time that must elapse before another alert of the same type is 
generated after the crossing of the same or lower threshold or 
Directory-full condition 
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Although you can perform either stage first, it is usually more logical to begin 
with volume-wide settings. 


Directory-Specific Settings for Alerts 

The following steps show you how you can limit the space for a directory and set 
directory-specific settings for alerts within the GUI. For information on how to 
set limits from the command prompt, see “NET DASD” on page 119. 
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1. 


2 
3. 
4 
5 


Select the Local Workstation icon as shown in Figure 119. 
Press the right mouse button. 


Select: Open —. 


. Select: Current shares > . 


. Select: Directories... 
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Figure 119. LS Administration - Icon View Window 


This shows you the Current shares window as shown in Figure 120. It 
includes a list of directory resources currently shared. .In our example we 
select the OS2TOOLS resource and pressed the Manage limits button. 
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Figure 120. ANYSRV02 - Current shares - Directories Window 
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If Directory limits checking has not been enabled on the drive you selected 
then you receive the window shown in Figure 121 on page 225. 











Directory limits checking has het 
been enabled on this drive, select 
OK ta enable the directory limits. 





Warning: this process may take a 
signifi¢ant amount of time. 
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Figure 121. Directory Limits Checking Not Enabled Window 


6. Select the OK button. 










ig! 


"NET2305: Support for directory Limits 
on the specified drive cannot complete 
at this time. The drive is in use or 
locked by another process. You must 
shut down and restart uour sustem in 
order for directory limits to become 
operational. " 








Figure 122. Application Message NET2305 


It might be that you receive the window shown in Figure 122. After that, 
simply select the OK button, shut down your system, and start again with the 
steps as shown before. 


After restarting the system and performing the steps shown before, you can see 
the Directory Limits window as shown in Figure 123 on page 226. 
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Figure 123. Directory Limits Window 


In Figure 123 we specify the following: 
* A Directory limit of 100MB 
* A threshold of 80% 


The threshold value is a percentage of the set directory limit. The valid range 
is 1 to 99. An alert is posted when the directory is this percentage full. 


* An increment of 3% 


The incremental threshold value is a percentage of the set directory limit. 
Valid ranges are values less than or equal to (100 - threshold value - 1). An 
alert is generated each time the directory increases by this incremental 
value after the threshold is reached. 


In our example the following happens: 


+ The first threshold alert is posted when the directory increases of 80 percent, 
(80 MB) of its limit (100 MB). 


* From that point, each time the directory increases 3 percent (3 MB) of the 
directory limit, another threshold alert is posted. Threshold alerts are posted 
as the directory grows to the following sizes: 80 MB, 83 MB, 86MB, 89 MB, 92 
MB, 95 MB and 98 MB. 


In Figure 124 on page 227, you can see a sample of a Directory-full alert. 
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Figure 124. Network Message NET3024 


Volume-Wide Settings for Alert 


You control settings for volume-wide alerts with parameters that you set in the 
HPFS386.INI file. The values for these parameters become active when you 
reboot the server. 


The following list describes the volume-wide parameters stored in the 
HPFS386.INI file. Some parameters control who receives alerts; others control 
the delay value. 

Parameters that control who receives alerts: 

Parameter Description 


DirFullAlertNames Specifies, on a per-volume basis, the user or group IDs to 
receive alerts when the size of a directory has reached the 
set limit. 


DirFullAlertUser Specifies whether a user ID that encounters a directory-full 
condition receives an alert. Specify either Yes or No. 


ThreshAlertNames = Specifies the user IDs to receive alerts when a threshold is 
exceeded. 


ThreshAlertUser Specifies whether a user ID that caused a threshold to be 
crossed requires notification. Specify either Yes or No. 

Parameters that control delays: 

Parameter Description 


DirFullAlertDelay Defines, in minutes, the ThreshDelay period for 
directory-full conditions. 


ThreshAlertDelay Defines, in minutes, the ThreshDelay period for the 
threshold crossing. 
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Format of Parameter Values 


The HPFS386.INI files stores volume-wide information patterned after the 
following format: 
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<parameter>=<drive letters>: argl arg2 ... argN 


where: 











parameter specifies the parameter in the DASD_Limits section of the 
HPFS386.INI file. 


drive letters specifies the drives to which the parameters applies. 


argl arg2 ... argN specifies the variable number of arguments to apply to 
this use of the parameter. Depending upon the parameter, arguments can be 
the name of subdirectories, user IDs, Yes or No, or a numerical value for 
minutes. 


Several rules apply to the HPFS386.INI file: 


The 


When used instead of drive letters, the * (asterisk) denotes all HPFS386 
drives. 


If the same parameter is specified with the same drives more than once, the 
occurrence positioned lower in the file overrides the previous occurrence. 


To add comment lines in the file, comment them out with semicolons as 
shown in the following example. 


following example shows the parameters are located under the 








[DASD_Limits] section of the HPFS386.INI file. 
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[DASD_Limits] 


*xk*x Threshold alert definitions ***** 



























































sAlertNames=*:useridl userid2 groupid1 ;For all 386 drives 
sAlertDelay=CDE: 60 ;1 hour delay for drivesC, D, E 
sAlertDelay=FG: 10 ;Delay for drives F andG 
sAlertUser=DE: Yes ;Notify user by sending a message 





*** Directory Full alert definitions ***** 


















































DirFullAlertNames=CDE: admins ;Notify all administrators 
DirFullAlertDelay=*: 5 ;Post alerts no less than 5 minutes apart 
DirFullAlertUser=DEG: Yes ;Notify user who requested space 
DirFullAlertUser=C: No ;No alerts to any user for drive C 











In Figure 125 on page 229 you can see the [DASD_Limits] section as a part of the 
HPFS386.INI file. 
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; The [DASD_Limits] section specifies settings of parameters for the DASD 

; Limits function. If you make any changes to these parameters they do not 

; take effect until you restart the server. (To stop and restart the server, 
; at an OS/2 command prompt, enter the command "net stop server" and then the 
; command "net start server".) 


; ThreshAlertNames = [drives:] [user1] 

* [user2] [group1] [group2]... 

H This parameter lists the users or groups that are to be notified when a 

; DASD Limits threshold is crossed on the specified drives. Any mixture of 
: user names or group names can be used. All of the names must appear on 

; one line. This line can be used multiple times to achieve the settings 

; you want for your drives. If ThreshAlertNames is not specified, the 

* default is to have no user or group names. 


ThreshAlertDelay = [drives:] nn 

This parameter specifies how many minutes to wait before sending another 
: alert for a threshold that was previously crossed on the specified 
drives. If a threshold is crossed more than once within the delay 
period, an alert is sent only for the first occurrence. An alert is sent 
if a higher threshold is crossed during the delay period. This parameter 
; is used to cut down on the number of alerts that can be generated when 


there is a lot of disk activity and the disk size is within the 
threshold. This line can be used multiple times to achieve the settings 
; you want for your drives. If ThreshAlertDelay is not specified, the 
default is 10 minutes on all drives. 


ThreshAlertUser = [drives:] yes|no 

; This parameter specifies whether to send an alert to the user whose disk 
usage caused a threshold to be crossed on the specified drives. This 
line can be used multiple times to achieve the settings you want for your 
drives. If ThreshAlertUser is not specified, the default is yes for all 
i drives. 


; DirFullAlertNames = [drives:] [user1] 

; [user2] [user3]... 

; This parameter lists the users or groups that are to be notified when a 
; DASD limit is reached. Any mixture of user names or group names can be 
; used. All of the names must appear on one line. This line can be used 
; multiple times to achieve the settings you want for your drives. If 

E DirFullAlertNames is not specified, the default is to have no user or 

; group names. 


; DirFullAlertDelay = [drives:] nn 

; This parameter specifies how many minutes to wait before sending another 
7 alert for a DASD limit that was previously reached. If a DASD limit is 

; reached more than once within the delay period, an alert is sent only for 
; the first occurrence. This parameter is used to cut down on the number 

; of alerts that can be generated when there is a lot of disk activity and 
: the DASD limit is reached several times. This line can be used multiple 
; times to achieve the settings you want for your drives. If 

; DirFullAlertNelay is not specified, the default is 10 minutes on all 

r drives. 











Figure 125 (Part 1 of 2). [DASD_Limits] Section as a Part of the HPFS386.INI File 
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DirFullAlertUser = [drives:] yes|no 
This parameter specifies whether to send an alert to the user whose 
request failed because a DASD limit was reached. This line can be used 
multiple times to achieve the settings you want for your drives. If 
DirFullAlertUser is not specified, the default is yes for all drives. 





DASD_Limits] 
ThreshAlertNames = *: ADMINS 
ThreshAlertDelay = *: 10 
ThreshAlertUser = *: yes 
DirFullAlertNames = *: ADMINS 
DirFullAlertDelay = *: 10 
DirFullAlertUser = *: yes 











Figure 125 (Part 2 of 2). [DASD_Limits] Section as a Part of the HPFS386.INI File 


386 Local Security 


Permissions that you set for a resource usually apply only to remote users 
accessing the resource from different workstations. LAN Server Advanced 
provides local security for the HPFS386 (referred to as local security). Local 
security extends access restrictions to local users working at the server. It 
protects all files on HPFS386 partitions of the server from unauthorized local 
access. Files stored on the FAT file system partitions are not protected by local 
security. However, they are still protected from remote access by unauthorized 
users. Administrators set permissions for all files on the server and are not 
subject to access control permissions. 


When you are working at a server with local security, you can access a file only 
if you have adequate permissions for that file. When you run a program, the 
program can access a file only if you have permission to access the file. Your 
permissions, not those of the program, control access to files. Local NetAPI calls 
are also subject to privilege checking when local security is active. However, an 
administrator can also start a program and give it special privileges. 


Local Security on a HPFS386 Server 


Local security protects files on HPFS386 formatted partitions on the server, 
regardless of whether LAN Server is running. When a local user tries to access a 
file on a HPFS386 partition on the server, local security checks the permissions 
for the file. Access is allowed only if the user has the required permissions. 

Local security also checks file permissions when you run a program that 
accesses files. 


File-access auditing is also improved on a server with local security installed. 
Auditing of files and directories on HPFS386 partitions on the server begins when 
the workstation is started, even if the server service is not started. 


Starting a Server with Local Security 
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When you start a server on which local security is installed, many programs are 
started. To ensure that the operating system and programs run successfully 
when no one is logged on to the server, give the special group LOCAL read (R) 
and execute (X) permissions to the files needed for the operating system and 
those programs. 
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Only administrators can start services on servers with local security. To help you 
set up correct permissions for system files, LAN Server displays the following 
prompt when a server with local security is started: 


LAN Server Local Security has started. 














Press Esc to log on now, or press ENTER to 
start the workstation with no one logged on. 





Press Enter to test whether the workstation initializes itself with no one logged 
on. If the workstation does not start successfully, restart it, and press Esc when 
the prompt is displayed. 


Note: This prompt is automatically removed after a short while, allowing the 
server to start automatically without intervention. For this reason, it is 
recommended that OS/2 and its Desktop be allowed to start with no one logged 
on. When the logon prompt is displayed, log on using a user ID that has 
administrator privilege on the server. You can adjust the server file permissions 
for the group LOCAL if you want the workstation to start with no one logged on. 


After you grant permissions for system files, log off so that no one else can use 
the administrator privilege on the server. 


Note: If you log on locally to a server with local security, log on to the network, 
and then log off from the network, you are still logged on at the local server. 


Accessing Files with Local Security 


LAN Server creates a special group called LOCAL on servers with Local 
Security. No users are member of this group nor may any users be added to it. 
The LOCAL group is a special group ID whose permissions are granted to the 
system or to users using the local system when no one is logged on. The LOCAL 
group does not show up in User Profile Management windows; however, it does 
show up in the LAN Server Administration GUI. 


Users working at the server workstation when no one is logged on receive the 
permissions granted to the LOCAL group. If you log on with user privilege, you 
have the permissions granted to your own user ID and to any groups of which 
you are a member, in addition to the permissions granted to the LOCAL group. 
If you log on with administrator privilege, you can access all files on the server. 


The following list provides a summary of permissions for a user working at the 
console of a server with local security: 


Local user not logged on Permissions granted to the group LOCAL, but no 
access to the network 


Local user logged on only to a local server Permissions granted to the group 
LOCAL and the user ID, but no access to the network 


Local user logged on to the network Permissions granted to the group LOCAL, 
the user ID, and access to the network 


Note: Both the user ID and corresponding password must be in the accounts 
database for the server running local security before LAN Server will grant 
network permissions. If LAN Server does not find a valid user ID, LAN Server 
grants only the permissions of the LOCAL group at the local server. 
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Running Privileged Programs at Startup 
Many programs must have access to all the files on the server. Only the 
administrator can start and run a program as a privileged program that can 
access all files on the server, whether or not anyone is logged on locally. 


An administrator has two ways to start a privileged program when the 
workstation starts: 


Edit the PRIVINIT.CMD file to add the command that starts the program. The 
PRIVINIT.CMD file is a special batch program, located in the root directory on 
the boot drive, that runs when a workstation with local security starts. Each 
command in the PRIVINIT.CMD file starts as a privileged program. 


Note: Starting PRIVINIT.CMD by itself does not make the programs in 
PRIVINIT.CMD privileged. Start the PRIVINIT.CMD file by specifying 
RUNPRIV.EXE in the STARTUP.CMD file. 


Commands in the PRIVINIT.CMD file are not automatically run as background 
programs. To start a background program from the PRIVINIT.CMD file, use 
the DETACH statement. For more information about the DETACH statement, 
see your base operating system documentation. 


+ Put the command to start the program in the CONFIG.SYS file using the RUN 
statement. Programs started with the RUN statement are always started as 
background programs. For more information about the RUN statement, see 
your base operating documentation. 


Commands in the STARTUP.CMD file are not run as privileged programs. 
Therefore, you must be logged on locally as an administrator to start LAN Server 
services from the STARTUP.CMD file. 


Note: To start a service automatically when the server starts and before anyone 
logs on at the server, put the NET START command (with the service to be 
started) in the PRIVINIT.CMD file. 


Running Privileged Programs from the Command Line 


To start a privileged program at the OS/2 command prompt once the server is 
running, type PRIV followed by the command to start the program. 





For example, to start the SORT program in the background, type: 





DETACH SORT <source> target 








To start the SORT program as a privileged background program, type: 





DETACH PRIV SORT <sSource> target 











Note: LAN Server services are an exception to this requirement. When started, 
LAN Server services are automatically treated as privileged programs. The PRIV 
command is not needed. 


When you start a program as a privileged program, the privilege applies only to 
that instance of the program. If you or another user runs the program again 
later, the program is not automatically privileged. This restriction applies to 
privileged programs started both from the command line and by the 
PRIVINIT.CMD file. 
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Programs started by a privileged program, regardless of how the privileged 
program was started, are also privileged. 


Local Security Guidelines 


On a server with local security, restrictions begin when the workstation starts, 
before system initialization files run. If you want the workstation to initialize 
when no one is logged on, the LOCAL group must have permission to run the 
server startup programs. 


To accomplish this, the LAN Services installation/configuration program 
automatically grants local permissions for certain files when local security is 
installed. 


Access Control Manager (ACM) 


This section shows you how to install and use the Access Control Manager. The 
Access Control Manager is an applet which comes with the OS/2 LAN Server 4.0 


Access Control Manager Utility 
The Access Control Manager (ACM) provides both administrators and users the 


ability to manage access control rules on servers in the network. 
Users can use the Access Control Manager to: 
Select a server to mange the access control profiles 
+ Scan drives and devices for access control profiles 
Edit access control profiles from a tree view 


Find lists of access control profiles to manage as a group 


ACM Installation 


The following steps show you how to install the Access Control Manager: 














Insert the first productivity aids diskette in drive A: and type AIDINST on the 
command prompt. 





* Select the ACM utility from the selection window as shown in Figure 126 on 
page 234. 


Press the Install button. 


Insert the diskette as prompted. 


After the installation, you can see that you have, in the LAN Services folder, a 
new folder called LAN Services Productivity Aids. 


To start the Access Control Manager, open the LAN Services Productivity Aids 
folder and double click on the ACM icon. 
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Figure 126. LAN Services Productivity Aids Installatio 


ACM Administration 
After you have started the Access Control Manager, the window in Figure 127 is 
wn. 
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Figure 127. ACM / Select Server Window 
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Figure 128. ACM / Main Window 


To administer the access control profile for the OS2TOOLS directory simply 
double-click on on the D: OS2TOOLS line in the tree. This brings you to the 
window in Figure 129. 
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Figure 129. ACM / Add/Edit Profile Window 


As you can see in Figure 129, you can now add user IDs, remove user IDs and 
change the permissions for user IDs. 
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HPFS386 and LAN Server Ultimedia 1.0 


There is an updated Version of LAN Server Ultimedia (Version 1.0.1) for installing 
with LAN Server 4.0. Do not install LAN Server Ultimedia Version 1.0 on top of 
LAN Server 4.0, as it will down-level some of the HPFS386 system files and 
cause them to work incorrectly. 


If you already have LAN Server Ultimedia 1.0 installed on your server, it is 

recommended that you delete LAN Server Ultimedia, using the LAN Server 
Ultimedia installation utility. Then install LAN Server 4.0 and reinstall LAN 

Server Ultimedia 1.0.1. 
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Chapter 11. Fault Tolerance Review 


Fault Tolerance (FT) changes in LAN Server 4.0 are: 


Boot drive recovery procedure now requires fewer modules, as shown in 
“Preparation for Boot Drive Recovery” on page 260. 


Disks of different geometries cannot be mirrored. Although this was allowed 
in LAN Server 3.0, there was a slight possibility of the data on the mirrored 
drive becoming unsynchronized with the primary disk. For more on this, see 
“1/0 Operations on Mirrored Drive” on page 244. 


The documentation of FT included with the product has been expanded. This 
chapter provides an overview of the FT process and examples of using it. 





OS/2 LAN Server 4.0 Fault Tolerance Terms 


OS/2 LAN Server 4.0 Fault Tolerance and other disk applications, such as 
FDISKPM, make use of many terms to describe the components of the disk 
subsystems. This is a summary of the main terms used: 


Fault 


A physical defect or imperfection that occurs within a hardware or software 
component. 


Fault Tolerance 
The ability of a system to continue operating after faults have occurred. 
(Logical) volume or drive 


A logical drive in the system, for example C:, corresponding to a fixed disk 

partition in a standard system. This drive could also correspond to a pair of 
fixed-disk partitions in a mirrored system. For example, the logical drive D: 
might consist of the OS/2 boot partition D: and its mirror, often denoted with 
a quote mark, as in D'. See Figure 130. 
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Figure 130. Fault Tolerance Terminology 
Disk 
A physical hard disk drive which could have logical drives and partitions. 


Disk controller 
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A peripheral device, typically on the card plugged into the I/O bus of the 
computer, that services one or more physical disks. Examples of disk 
controllers include a SCSI controller or IDE controller. 


Partition 


A section of a physical disk, containing primary or secondary (mirrored) 
data. 


Drive mirroring 


The duplication of a single logical drive or volume on two partitions which do 
not reside on the same physical disk. The physical disks on which the 
partitions reside are controlled by the same disk controller. See Figure 131. 


DRIVE MIRRORING 
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Figure 131. Fault Tolerance Disk Mirroring Example 


Drive duplexing 


A superset of drive mirroring, with the additional restriction that the two 

disks on which the two partitions reside are controlled by two different disk 
controllers ensuring the continued availability of the drive in the event of a 
controller failure. See Figure 132 on page 239. Mirroring and Duplexing can 
be combined in the same system. 
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Figure 132. Fault Tolerance Disk Duplexing Example 


Primary partition 


The partition of a mirrored pair of drives which is visible to the operating 
system. This term is also used by FDISKPM to indicate potentially bootable 
partitions on a fixed disk. 


Secondary partition 


The partition of a mirrored pair of drives which is invisible to the operating 
system, being managed solely by the Fault Tolerance subsystem. This is 
essentially the backup partition. 


Extended partition 


This term is used by FDISKPM to indicate the area of a fixed disk that is left 
over after the primary partition has been configured. The extended partition 
is where one or more logical drives might be created. 


* Alternate partition 


Used to refer to the other partition of a pair of partitions comprising a 
mirrored drive pair. Thus, the alternate of the primary is the secondary; the 
alternate of the secondary is the primary. 


Mirrored drive or mirrored drive pair 


A primary drive partition plus a secondary drive partition which are mirrored 
or duplexed, and appear in the operating system as a logical drive. 


Redundant Array of Inexpensive Disks (RAID) 


A collection of disks and an intelligent controller (either in hardware of 
software) providing varying levels of Fault Tolerance. There are different 
levels of RAID function classified into numbered layers currently from 0 to 5. 
These can be summarized briefly as follows: 
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Table 12. RAID Classifications 

RAID Level Description 

RAID-O Block Interleave Data Striping without Parity 

RAID-1 Disk Mirroring/Duplexing 

RAID-1 (Enhanced) Data Stripe Mirroring 

RAID-2 Bit Interleave Data Striping with Hamming Code 

RAID-3 Bit Interleave Data Striping with Parity Check 

RAID-4 Block Interleave Data Striping with one Parity Disk 

RAID-5 Block Interleave Data Striping with Skewed Parity 

Orthogonal RAID-5 RAID-5 with additional redundancy (such as disk 
adapters) 





The different levels require different amounts of redundant (backup) disks, 
different levels of recoverability and so on. Various manuals describe RAID 
in more detail. The IBM ITSO redbook Understanding IBM OS/2 LAN Server 
Performance Tuning is one such manual. 


Hot Fix 





A function of the High Performance File System (HPFS) whereby write errors 
are recovered by directing all future requests for a bad disk sector to a good 
sector out of a reserved pool. Hot fix is always accomplished transparently to 
the operating system and the user process, without loss of data. When 
CHKDSK is run, bad sectors are marked permanently (until the disk is 
formatted) as unusable, and the hot fix pool is replenished with new, good 
sectors. OS/2 LAN Server will log a message (NET3181) when this occurs so 
the administrator will know if a CHKDSK is required to replenish the hot fix 
pool. 


Verify 


A function of OS/2 LAN Server 4.0 FT utilities FTADMIN and FTREMOTE, 
where the primary and secondary partitions are compared. When a 
mismatch is detected, the data from the good partition is copied to the 
partition having errors. Verify can be invoked by a user or can run 
automatically as a result of a user correcting an error. 


Mirrored Read 


A read operation from a disk which is being mirrored or duplexed. The read 
may be accomplished from the primary partition or the secondary partition, 
whichever is likely to respond fastest. 


Mirrored Write 


A write operation to a drive which is being mirrored or duplexed. The result 
is actually two requests, one for each partition. 
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Fault Tolerance Description 


Many methods have been developed over the years to protect loss of data from 
fixed disk failure. Many of these keep extra copies of the data via redundant 
arrays of inexpensive disks (RAID). However, most methods of RAID 
implementation required additional software and specialized hardware. OS/2 

LAN Server 4.0 Advanced includes a disk Fault Tolerance subsystem that 
implements a level of RAID (level 1), through HPFS386 working in conjunction 
with the OS/2 DASD Manager. Changes to application programs and hardware 
are therefore not required since this Fault Tolerance support is integrated in the 
LAN operating system. In addition, FT can work in conjunction with RAID devices 
to provide the maximum recoverability of data as required. 


Since the introduction of HPFS386 in OS/2 LAN Server 2.0 Advanced, you had the 
ability to mirror and duplex disk drives. This is part of the FT subsystem. Disk 
mirroring and duplexing provide protection of your data should errors occur on 
your physical disk or if you lose your disk completely. This is accomplished by 
writing two copies of your data on two physically different disk volumes. Should 
one volume fail, the operating system will automatically read and write your data 

to and from the remaining volume. Thus, the system has the capability to 

continue operation until a time when it can be brought down in an orderly 

manner for drive repair. 


OS/2 LAN Server 3.0 Advanced, added the following: 


* The ability to mirror or duplex your boot drive. 


+ The setting up and administering of FT from a remote workstation by using 
the FTREMOTE utility. 


+ The ability to mirror a partition without having to first format the source. 
There are special considerations that will ensure smooth access to this feature. 
Planning is critical to successful implementation of mirroring and duplexing 


drives (including the boot drive). You need to understand your present 
requirements, and more importantly, understand your future requirements. 


Note: OS/2 LAN Server 3.0 should be at level IPx7001 or above for FT to work 
correctly. 


Fault Tolerance Subsystem Structure 
The Fault Tolerance subsystem consists of the following programs: 


DISKFT.SYS - Fault Tolerance driver 
+ FTMONIT.EXE - background fault monitor 
FTSETUP.EXE - PM-based configuration program 
FTADMIN.EXE - PM-based administration program 
FTREMOTE.EXE - response file configuration/administration program 
FT.DLL - support functions 
Figure 133 on page 242 shows the interactions between the different 


components. See “Fault Tolerance Utilities Overview” on page 246 for further 
information on these programs. 
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Figure 133. Fault Tolerance Subsystem Structure 


The following scenarios show how each type of disk activity is handled. 


Read requests scenario 
When a read request is made by HPFS, the DASD Manager informs 
DISKFT. DISKFT determines which drive has been requested. If both 
sides of the mirror are healthy, DISKFT tells the DASD Manager to 
read from either side of the mirror. The DASD Manager looks at the 
queue length for the entire fixed disk and schedules the read request 
for the least busy disk. 


When the read request completes, the DASD Manager informs 
DISKFT. DISKFT increments the drive statistics, determines the 
correct return code for the read, and tells the DASD Manager the 
read request is complete. 


Write requests scenario 
When a write request is made by HPFS, the DASD Manager informs 
DISKFT. DISKFT directs the DASD Manager to write to the primary 
partition. In addition, DISKFT generates a second write request to the 
secondary partition. 


When the DASD Manager informs DISKFT that both write requests 
have been completed, DISKFT increments the drive statistics, 
determines the correct return code for the write, and tells the DASD 
Manager that the write request is complete. 


Read failure scenario 
If the first read request completes unsuccessfully, the DASD Manager 
informs DISKFT. DISKFT increments the drive statistics, and tells the 
DASD Manager to read from the other side of the mirror. If the 
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second read is completed successfully, DISKFT sets the return code 
to read with recovery. \f the second read is unsuccessful, DISKFT sets 
a failure return code. 


DISKFT tracks the number of failures. If 16 out of 32 requests fail, 
DISKFT informs FTMONIT of the problem and stops directing read 
requests to the error-prone partition. FTMONIT logs an error and 
sends an alert. 


Disk failure scenario 
If errors continue to happen on an error-prone partition or if the DASD 
Manager is unable to access the partition, DISKFT shuts down the 
failing partition. All read and write requests are directed only to the 
good side of the mirror. DISKFT informs FTMONIT of the shutdown 
drive. FTMONIT logs an error and sends an alert. 


System Requirements 
Fault Tolerance requires: 


OS/2 V2.0 or above 


+ OS/2 LAN Server Advanced (we are assuming the use of versions 3.0 and 
above here) 


HPFS386 of the same LAN Server level 
Fault Tolerance device driver DISKFT.SYS of the same LAN Server level 


The OS/2 base operating system DASD Manager includes the interface to the 
fault tolerant feature. It is no longer necessary for the LAN Server to provide a 
Fault Tolerance enabled disk device driver as it did in OS/2 LAN Server 2.0 for 
OS/2 1.3 Standard Edition. 


Fault Tolerance supports any drive type supported by OS/2. FT will allow 
mirroring between dissimilar drive/controller types assuming all conditions for 
mirroring a drive are correct. (See the conditions notice in the “Running the 
FTSETUP Program” on page 249 for details). Therefore, it is possible for 
example to have ESDI/SCSI duplexing. 


The FT driver will support up to 24 fixed disk partitions where a 
mirrored/duplexed pair comprising a logical volume counts as two partitions. 


General Configuration Information 


An internal table is maintained to describe the status of each partition in the 
system. A partition can be an unmirrored partition, a primary partition which has 
a mirrored secondary, or a primary partition's secondary. Each partition that is 
part of a mirrored drive has an associated status with respect to the mirror. This 
indicates the current request routing mode of the partition with respect to its 
alternate. 


Configuration information is replicated on the active partition of the primary 
system fixed-disk and each volume. FTCFG.SYS is located in the root of the C: 
drive and contains information for each drive in the system and its status. 
FTCFG.DRV resides in the root of each fixed disk volume in the system, and 
contains redundant mirroring configuration information for only the drive on 
which it resides. Note that the FTCFG.DRV file, like any file on a mirrored drive, 
is duplicated on both the primary and secondary partitions for the mirrored 
drive. 
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I/O Operations on Mirrored Drive 


The user may perform the following operations on mirrored drives, without side 
effects: 


Reformat a mirrored drive for HPFS 
« Run utilities that use category 8 IOCTLs, DASD-based volume access, and 
file I/O to modify the disk 


-—— Same Geometry Rule in LS 4.0 FT 





In LAN Server 4.0, the primary and mirrored drives must be of the same 
geometry . The disk geometry is the number of sectors/track and the number 
of heads on a disk. System utilities, such as CHKDSK and FDISK, use 
category 8 IOCTLs to do I/O; other application programs can also use 
category 8 IOCTLs. This means that they write data to a disk using 
head/sector location. (The cylinder number is calculated by the DASD 
manager.) 


The size of a disk is determined by sectors/track, heads, and cylinders. So, 
disks of different sizes may have the same disk geometry. (For IBM 
employees, the DISKMAP utility on the OS2TOOLS tools disk will provide 
information about disk geometries. Use the /P parameter.) 


When category 8 I/O is done on a mirrored drive, I/O is done to both 
partitions. Therefore, the head/sector location must match. The only way to 
ensure this is to enforce the same geometry rule for mirrored drives. 


Drives of different geometries that were mirrored by LAN Server 3.0 will 
remain mirrored under LS 4.0. However, new mirrors of drives with 
non-matching geometries cannot be created. Also, to protect from CHKDSK 
problems, you should verify a drive following a CHKDSK. You may also 
experience problems with FDISK forcing mirrored drives to become 
unmirrored. 





The user must not perform the following operations on mirrored drives: 


¢ Reformat a mirrored drive for a file system other than HPFS, without first 
unmirroring it through FTSETUP 


* Delete a partition that is part of a mirrored drive, without first unmirroring it 
through FTSETUP 


« Run utilities on mirrored volumes that use category 9 IOCTLs, or real mode 
INT 13H or 26H to modify the disk. (Under OS/2 the DASD manager will not 
allow direct disk access by an application) 


+ IPL the computer without Fault Tolerance and write to a mirrored drive 
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Workstations with Boot Manager Installed 


OS/2 2.x provides the Boot Manager utility. This provides a method to install and 
use multiple operating systems on a single workstation. Special care must be 
taken when Fault Tolerance is used on system containing the Boot Manager. 
Some considerations are: 


OS/2 2.x FDISK allows multiple primary partitions. Fault Tolerance cannot 
mirror a primary partition unless it is placed at the beginning of a fixed disk. 
If you want to mirror your IPL drive and define the IPL partition as primary, it 
is possible, but can cause a problem during recovery due to the fact that 
when FT recovers a detached secondary partition, the recovered FT primary 
will always be a logical (not FDISK primary) partition. If the original primary 
partition was the OS/2 primary partition, the recovered partition can only be 
an OS/2 logical partition which will not be bootable. It would be necessary to 
add boot manager to the disk in order to boot that partition. 


Note: It is recommended that all the partitions, that could be mirrored on 
disk 1, be created as logical drives. 


Fault Tolerance keeps its configuration information on the C: drive, 
regardless of which operating system is IPLed. 


+ Whenever possible, FT should be installed and activated in each of the 


bootable operating systems. This will ensure mirrored drives remain in 
synchronization. 


* When running non-FT enabled operating systems, write operations must not 


be done to a mirrored drive. This may cause unpredictable results when FT 
is active again. 


If you suspect write requests were done to mirrored drives, add the 
READPRIM parameter to the DISKFT line in CONFIG.SYS before IPLing an 
FT enabled operating system. Once the system is active, run FTADMIN or 
FTREMOTE to verify all mirrored drives. Remove the READPRIM parameter 
and reboot the FT-enabled operating system. 





Fault Tolerance and Local Security 


Both features can be installed on the same server machine. You must be logged 


on 


as a user with the correct access rights before invoking FTSETUP, otherwise 


you'll receive the following message: 





FT] 











DO512E: An unexpected error occurred while parsing the CONFIG.SYS 


file 


You can invoke FTADMIN from a requester machine when logged on with the 


cor 


rect access. 
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Fault Tolerance Utilities Overview 


FTSETUP.EXE 


FTADMIN.EXE 


FTREMOTE.EXE 


The Fault Tolerance subsystem is provided with tools to install, monitor, and 
administer mirrored and duplexed drives. These tools are described in this 
section. 


FTSETUP is the installation tool for mirroring. This is a Presentation Manager 
(PM) application which activates disk Fault Tolerance and configures your drives 
to use Fault Tolerance. 
FTSETUP guides the user through the following operations: 

+ Activating Fault Tolerance, including fault monitoring 

* Selecting drives to mirror 

+ Finding available disk space to use for secondary partitions, if required 

Creating secondary partitions, if required 


+ Formatting of mirrored drives, if required (formatting secondary partition only 
if primary already formatted or containing data) 


+ Recovery of detached secondary drives, if any 
¢ Unmirroring a drive 
+ Deleting a drive 


Deactivating Fault Tolerance 


FTADMIN is a PM application, which is the administrator's interface to the Fault 
Tolerance subsystem. It can be invoked from a requester or directly on the FT 
server. This program provides: 


+ Viewing local or remote disk information 

* Verifying and resynchronizing mirrored drives 
+ Viewing and correcting disk faults 

+ Viewing error rate statistics 


+ Setting and resetting LAN alerts from FTMONIT 


FTREMOTE is a response file driven version of FTSETUP and FTADMIN. It 
activates Fault Tolerance, configures the drives to use Fault Tolerance in an 
unattended state, verifies mirrored drives, and corrects errors. FTREMOTE is 
invoked via the Configuration Installation Distribution (CID) utility for remote 
installation of programs. FTREMOTE can also be run after the system has been 
started from HPFS386 boot diskettes or from a maintenance partition with a 
response file to recover a failed system that cannot be started from the normal 
boot drive. 
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FTMONIT.EXE 


FTMONIT is designed to monitor the Fault Tolerance driver events. If drive 
mirroring or duplexing is in effect, FTMONIT is best started with a RUN= statement 
in your CONFIG.SYS file. This statement is automatically added to your 
CONFIG.SYS file when Fault Tolerance is first invoked. FTMONIT can also be 
invoked from the OS/2 command line to enable or disable alerting and to clear 
statistics. When FTMONIT is started, it does some initial consistency checks on 
mirrored/duplexed drives and on the FT configuration. It then begins monitoring 
for disk errors. When an error is detected, it logs the error, sends alerts (if 
needed), and waits for the next error. 


lf an error is detected by FTMONIT, an alert is sent to the userid listed in the 
ALERTNAMES parameter of the IBMLAN.INI file. 


In addition, if Generic Alerter and FFST/2 services are installed and configured, 
the alert will be sent to a central point of management, such as NetView or LAN 
Network Manager. 


Fault Tolerance Driver DISKFT.SYS 


The FT driver is a separate disk driver with the necessary logic to support drive 
mirroring. The FT driver cooperates with the system disk device driver 
(described as the DASD Manager in OS/2 2.x). 


The FT driver provides a number of functions for a cooperating disk device 
driver. It will: 


Find a secondary partition that will satisfy a read request for a mirrored 
drive, for error recovery or performance optimization 


Duplicate write requests for a mirrored drive on both the primary partition 
and the secondary partition 


+ Track completion of the two mirrored write requests associated with a single 
write command to a mirrored drive 


Route all requests to one partition of a mirrored drive either when the 
alternate fails, or for administrative functions 


Report error conditions for logging and alerting 
A primary goal of the FT driver is to provide these functions at minimum impact 


to the disk driver; thus isolating Fault Tolerance logic in the installable FT driver 
and supporting subsystem components. 
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Setting Up Mirroring and Duplexing 


Installing Fault Tolerance, setting it up, configuring the drives to be mirrored, and 
mirroring the drives is straightforward. 
Basically, the installation procedure is: 

1. Plan your network 

2. Partition the disk(s) 

3. Install OS/2 2.x operating system 

4. Install LAN Server 4.0 Advanced 

5. Set up Fault Tolerance 

6. Mirror drive(s) 


Note: For drives larger than 1GB, OS/2 LAN Server 3.0 required ServicePak 
IPx7001. There is no such restriction in OS/2 LAN Server 4.0 


Partitioning Fixed Disks with FDISKPM 
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The extra steps involved in changing partition information in an FT environment 
make it important to plan for the future. It is better to over commit now than have 
to repartition later. The following is a good guideline: 


1. Plan your disk space to take into account future requirements 
2. Installation of Boot Manager is strongly recommended 

3. Install OS/2 2.x into a logical partition 
4 


. Using FDISKPM, create the required logical drives that will be the primary 
mirror partitions 


5. Using FDISKPM, verify enough space is available on the remaining disks for 
mirroring 


FTSETUP will automatically create the FT secondary partition from the active 
disks other than the one with the FT primary partition. A disk for the FT 
secondary will be chosen if it is either unpartitioned and has enough free 
space or if it has an extended partition defined with enough free space. Do 
not use FDISKPM to create a logical partition for the secondary FT partition. 
FTSETUP has to do this itself. FTSETUP scans available disks to determine 
where to mirror a partition. There is no direct control over this by the user. 
FTSETUP first tries to use duplexing and if it cannot, it will use plain 
mirroring. It is possible to foo! FTSETUP into using a drive you choose by 
temporarily defining logical drives, using FDISKPM on disks that you do not 
wish your partition to be mirrored on. 


Note: From LAN Server 3.0, the C: drive can be mirrored or duplexed. If this 
partition is defined as a primary partition, it must be placed at the beginning of 
the disk (that is, before anything else such as Boot Manager). 


Note that it is possible to define logical partitions with FDISKPM without a 
primary partition. It is recommended to define the OS/2 C: drive as a logical 
partition and to create a Boot Manager partition to boot it. This allows Boot 
Manager to be at the start of the disk; it means that the OS/2 boot partition is not 
a primary partition and makes the administration and recovery simpler, 

especially under OS/2 LAN Server 3.0. 
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Running the FTSETUP Program 


After partitioning and installing OS/2 2.x and LAN Server Advanced, you can 
proceed to start the mirroring process. 


From the command line, type: 


FTSETUP 





This will start the Fault Tolerance Setup program. You will see the System 
Capabilities window (as in Figure 134), which will tell you whether FTSETUP will 
allow only mirroring or mirroring and/or duplexing. FTSETUP will list all the 
drives accessible in your system and the mirroring status of those drives. 





Figure 134. FTSETUP Fault Tolerance Activation 


Select Activate for FTSETUP to alter the CONFIG.SYS to initiate Fault Tolerance 
on this system. 
The following definitions are made in CONFIG.SYS: 

- Device driver DISKFT.SYS added 

+ Fault Tolerance Monitor Program FTMONIT.EXE is included in a RUN= 


statement 


Activation is complete. Changes in CONFIG.SYS will be effective after the next 
IPL. You can now define your drives to be mirrored before restarting the 
workstation. 
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Figure 135. FTSETUP Activation Complete 


There are important mirror conditions that must be met: 
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-— Important Mirror Conditions 


The following conditions must be met before a drive can be mirrored: 
* The system must have at least two fixed disks available to FT 


* Disks to be mirrored must have the same number of sectors per track 
and the same number of tracks per cylinder. Note that this was not 
checked by FTSETUP before OS/2 LAN Server 4.0 and certain OS/2 
functions (including work with FDISKPM) could cause mirrors to be 
broken if mirroring was performed across drives with a different 
geometry 


* Sufficient contiguous disk space must be available on a drive that does 
not contain the FT primary partition 

+ The limit of 24 primary and secondary partitions must not have been 
reached 


+ Primary partitions must be at the beginning of the disk space to be 
mirrored 








* Diskettes and RAM disks cannot be used for drives 


FTSETUP will show the status of each drive. For example as Cannot mirror, Not 
mirrored and so on. You can use the Options, Available space to view how much 
free space FTSETUP has determined is available. 

Highlight the drive to be mirrored, and select Drive. 


Then select Mirror. 


A warning about a Locked Drive Error will appear if the disk is in use by another 
process (such as the IPL drive). 


Bei 





Figure 136. FTSETUP IPL Drive Mirroring 


Select Mirror on this warning to continue. 


Mirroring Complete 
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Mirroring setup is complete. FTSETUP will save the changes in FTCFG.SYS and 
FTCFG.DRV. You should then exit FTSETUP (with F3). The system will warn you 
changes need to be made to the FT tables. Select OK to continue, the drive 
status will now change to pending mirror. 
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Figure 138. FTSETUP Modifications in FTCFG File 
















If the FT primary partition contains any data, copying is done when you select 
Save. This obviously could take some time. The time required will vary 
depending on the amount of data, size of disk, speed of controller, and so on. 





Figure 139. FTSETUP Copying Data 
You will receive an exit message, and then you can shut down and re-IPL your 
system. 
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Figure 140. FTSETUP Exiting 


Now the C: drive is in a mirroring state. Information regarding any drive is 
available with the following operation in FTSETUP: 
1. Highlight the desired drive, and select Drive. 


2. Then select Details. 
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Figure 141. FTSETUP Drive Details Screen 


At this point, your system is mirroring data between your FT primary partition (C: 
drive in this case) and your FT secondary partition. This is invisible to the 
operating system and the user. Reads for the data may come from either 
mirrored drive. The Fault Tolerance administration program, FTADMIN, will show 
you the number of reads and writes from the mirrored drives. The device driver 
will direct reads to the drives in an intelligent manner. If the fixed disk containing 
the primary partition is busy, the read will probably come from the FT secondary 
partition. 





Other FTSETUP 


Functions 


FTSETUP is a general administration tool for altering the status of FT drives. This 
section details some of its other functions. 


Recovery of Detached Secondary Partitions 


FTSETUP also allows the user to perform the recovery of detached secondary 
partitions. That is a secondary partition that no longer has a corresponding 
primary partition. This can happen if a mirrored drive is deleted by FDISKPM 
leaving the secondary (mirror) detached, or if the disk containing the primary 
partition of the mirror fails. Since OS/2 does not see this partition as a valid 
logical drive, it cannot be used until it is recovered. The following possibilities 
exist: 


* Leave the drive unmirrored 


Recover the partition as an unmirrored drive, so the drive becomes a non-FT 
drive and will have a logical drive letter after IPL. 


* Make the drive the primary partition of a mirror 


Recover the drive and mirror it. This option is not valid if 24 partitions have 
been created or if there is not enough disk space to mirror the drive. 


+ Make the drive the secondary partition of a mirror 
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Recover the drive and mirror it, making it the secondary of the new mirrored 
drive. This option is not valid if 24 partitions have been created or if there is 
not enough disk space to mirror the drive. 


See “Recovery Methods Overview” on page 258 and IBM OS/2 LAN Server 4.0 
Network Administrator Reference Volume 3: Network Administrator Tasks for 
further details on recovery. 


Unmirroring a Mirrored Drive 


Delete a Drive 


There will be times when you may want to unmirror a mirrored drive. You may 
have a requirement for the disk space, or you may need to recover from a disk 
failure. 


Choosing Unmirror in the Drive menu allows for the separation of primary and 
secondary partitions of a mirrored drive into two separate logical drives. Any 
logical drive with the status of Mirrored or Pending Mirror is available for drive 
unmirroring. 


Unmirroring your FT secondary partition is a simple process. The FTSETUP 
program will unmirror the drive, and make it available to the operating system. 
Unmirroring is simply modifying the FDISK disk partition table to change the FT 
secondary partition to a standard OS/2 logical drive. 


Because the partition table has been modified, you will need to shut down your 
system. When your system has restarted again, you will have an extra drive 
available to you. This drive was your FT secondary partition. All the data that 
had been mirrored is still there. 


Warning 





As a new drive has been made available to the operating system, drive 
letters may have been changed. This may affect the operating system and 


your applications (through the PATHs, INI files and so on). 


Delete a Drive allows for the deleting of valid logical drives. Any logical drive 
with the status of Not Mirrored or Pending Unmirror is available for deletion, 
except for the IPL drive. 


If you want to delete a drive that is currently mirrored, you must first unmirror 
the drive. 


Deactivate Fault Tolerance 


Under Options, selecting Deactivate Fault Tolerance performs the following: 





Removes the RUN=FTMONIT.EXE and DEVICE=DISKFT. SYS lines from the 
CONFIG.SYS file. 
































* All drives that are mirrored or pending a mirror are unmirrored and their 
secondary partitions deleted. 


* All detached partitions are recovered. 


The system will need to be restarted. 
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Partition Status 


As previous examples have shown, a partition can be in different types of status. 
The partition status is the current status of the logical drive or partition specified 
by a drive letter. Partitions can have the following status: 


Cannot Mirror 


This is assigned to all drives that do not satisfy the requirements for 
mirroring. 


* Not Mirrored 
This indicates a drive is not mirrored and is a candidate for drive mirroring. 
Mirrored 
This indicates a drive is mirrored and is a candidate for drive unmirroring. 
+ Detached 


This indicates a mirror no longer has a primary partition associated with it. 
Any partition with this status has a ? assigned to it as a drive letter. 


Pending Mirror 


This indicates a drive has been selected for mirroring and already has a 
secondary partition associated with it. The drive is not mirrored until the 
system is restarted. 


Pending Unmirror 


This indicates a drive has been selected to be unmirrored and its secondary 
partition exposed as a valid logical drive. The drive will become unmirrored 
when the system is restarted. 


* Pending Recover 


Indicates a detached secondary partition has been recovered. The drive will 
be assigned a drive letter when the system is restarted. 


* Recover/Mirror 


Indicates a detached secondary partition has been recovered and mirrored 
again. The newly mirrored drive will be available when the system is 
restarted. 


* Deleted 


Drives that have been selected to be deleted will not be displayed in the list. 


FTADMIN - Administration Program 
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The FTADMIN program allows the administrator to view statistics for the selected 
mirrored drives, such as: 


Number of reads and writes from the FT primary and FT secondary partitions 
Number of recovered and unrecovered faults 
Number of HPFS hot-fixed faults 

FTADMIN can be run at the server's workstation or remotely at an OS/2 LAN 


Requester workstation. To permit remote access, you must select the Fault 
Tolerance Administration component during the requester's installation. 


To start the FTADMIN program from the command line type: 


Inside OS/2 LAN Server 4.0 








FTADMIN servername 





The option Verify is available under FTADMIN. Verify allows you to check the 
drives in a mirrored pair for differences in the data between drives. Verification 
consists of reading all allocated sectors on both partitions of a mirrored pair and 
comparing the data. If a discrepancy exists, the data is copied from the error 
free drive to the drive containing the error. You will use this facility to recover 
from a cracked mirror situation. See “Cracked Mirrors” on page 258 for more 
information. 


FTREMOTE - Remote Administration Program 
FTREMOTE is a response file driven version of FTSETUP and FTADMIN that: 
Activates Fault Tolerance 
Configures the drives to use Fault Tolerance in an unattended state 
Verifies mirrored drives 


Corrects errors 


FTREMOTE has the following syntax: 








--FTREMOTE--/R:ResponseFil --------— ---------—- 
-/L1:StatusFile- -/L2:HistoryFile- 











Where: 
ResponseFile is the name of the input response file. 
StatusFile is the name of the output status file. 
* HistoryFile is the name of the history file. 


Note: Running FTREMOTE causes Fault Tolerance activation, unless the 
command DEACTIVATE is contained in the response file. 




















Response File Format 
The response file contains two main sections, the Current section and the 
commands section. An example of a typical response file for FTREMOTE with both 
sections present follows. 


Current < 








Drive Location Status 

Cc 1:308 Not mirrored 
D 21. Not mirrored 
E 2:105 Not mirrored 
? Sn Detached > 





commands < 
recover loc=3:1 secondary > 














Figure 142. FTREMOTE Response File Sample 


Current Section 
The optional Current section allows the user to specify the possible 
configuration of the system. If this section is present, FTREMOTE 
verifies that each drive described in the Current section is in 


Chapter 11. Fault Tolerance Review 255 


256 


agreement with the actual system. The Current section is not required 
to contain the entire system configuration. If a drive is specified 
incorrectly or does not exist, FTREMOTE writes the appropriate 
messages and completes processing the current section. FTREMOTE 
will not process any commands from the commands section. If the 
Current section is not included in the response file, then all possible 
commands in the commands section are carried out. See Section 
“FTREMOTE Usage” on page 257 for the suggested usage. 


Commands Section 
This section of the response file is optional too. It may contain any 
commands normally issued through the FTSETUP utility, as well as 
the VERIFY and CORRECT commands found in FTADMIN. 


Drive specification can be done in two ways: 
1. By drive letter, valid drive letters are C: through Z: 
2. By using the LOC=xx.yyy option, where xx is the physical drive number and 


yyy is the starting cylinder number of the primary drive 


These methods of drive specification can be used on any of the commands 
requiring a drive except for the RECOVER command. 


Refer to IBM OS/2 LAN Server 4.0 Network Administrator Reference Volume 3: 
Network Administrator Tasks for more details. 








Fault Tolerant Utility FTREMOTE - Version 4.0 

















Drive Location Status 
Cc : (3:1) Mirrored 
D L:308 Not mirrored 
E 2:105 Cannot mirror 











The total available space for mirroring is 465 MB. 
The largest contiguous space is 187 MB. 

















Drive Error Information 





There are no errors on drive C. 
There are no errors on drive D. 








Figure 143. FTREMOTE FTSTATUS File Sample 


The status file gives the list of the drives, their location, their status, and drive 
error information. 
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FTREMOTE is loading the file ftrec.log into memory. 
FTREMOTE has successfully loaded the file ftrec.log into memory). 























FTREMOTE is processing the CURRENT section of ftrec.log. 
FTREMOTE has successfully processed the CURRENT section of ftrelc.log. 


























FTREMOTE is processing the COMMAND section of ftrec.log. 




















FTREMOTE is recovering the drive at location 3:1. 
Status: The drive at location 3:1 has been recovered 
and mirrored as drive C. 

















FTREMOTE has ended successfully. 








Figure 144. FTREMOTE FTHIST File Sample 


The history file, FTHIST, contains a trace of all executions of FTREMOTE. When 
this information is no longer needed, you can delete this file. 


FTREMOTE Usage 
Here is an example of steps to use FTREMOTE: 
1. Run FTREMOTE with the Current section empty. For example: 
Current <> 
2. Create your real response file by specifying the list of drives, locations and 


status, found in the FTSTATUS.LOG file obtained in step number 1 within the 
Current section. Append to this your appropriate command section. 


3. Run FTREMOTE with the response file created in step number 2. 
4. Verify the execution in FTHIST file. Correct and rerun if necessary. 
5. Verify the accuracy of the results in the FTSTATUS file. 


Note: The location of the drives are the locations effective after re-IPLing 
your system. 


Starting FTREMOTE Using CID 


FTREMOTE can be started using a Software Distribution Manager (SDM) such as 
the LAN Configuration Installation Distribution Utility (CID). If you want to use 
FTREMOTE remotely, you must prepare a FTREMOTE response file and generate 
a client command file used by the CID utility. Here we assume FTREMOTE 
execution along with OS/2, NTS/2 and OS/2 LAN Server 4.0 installation through 
CID. The required steps are: 


1. Edit a client scenario file and include the following statements and keywords. 
It is recommended to designate a local path for FTREMOTE in order to 
ensure EXE files and the associated DLLs are at the same level. 











:Utility FTREMOTE 
name = Fault tolerant remote activation 
invoke = C:\IBMLAN\NETPROG\FTREMOTE. EXE 
/ce:"rsp_dir"\1s30\"client".ft 
/11:"log_dir"\1s30\"client".11 
/12:"log_dir"\1s30\"client".12 






























































:endutility 
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The status and history files designated by the 11 and 12 parameters may 
reside on either the client or remote server and so therefore may or may not 
use a redirected drive in their paths. 


2. Include an install keyword to invoke FTREMOTE after LAN Server. 


:install keywords 
SEINST+LAPS+THINIFS1+THINIFS2+THINIFS3+CASINSTL 
LANINSTR 

FTREMOTE 

IFSDEL+CASDELET 

:endinstall 


This scenario will execute FTREMOTE from STARTUP.CMD after LAN Server 
is installed. A reboot will be initiated before and after the FTREMOTE 
execution. Refer to Chapter 16, “OS/2 LAN Server 4.0 CID Enablement” on 
page 359 for more information on a CID installation. 


3. Generate a REXX command file for the client using the CASPREP utility. 




































































4. Create clientname.FT response file for FTREMOTE. The following is an 
example to activate the mirroring of the drive D: and E: assuming D: starts 
from cylinder 1 of disk 2 and E: starts from cylinder 161 of disk 2. 
COMMANDS < 

mirror loc=2: 
mirror loc=2:161 > 

















Note: Make sure the starting cylinder number is equal to the existing drive 
boundary created by FDISK or FDISKPM. 


5. Run the CID remote installation. 





Recovery Methods Overview 


Fault tolerance is designed to tolerate and allow recovery from faults. 
Administrative facilities are provided to automate recovery from errors that are 
not automatically recovered and to advise the administrator of the best method 
to recover from complete hardware failure. 


Self-Correcting Errors and Correctable Errors 


Cracked Mirrors 


During normal operation, bad sectors may be encountered. On write operations 
destined for HPFS, such errors are recovered automatically. For read operations 
on mirrored systems, data is always recovered correctly, and HPFS is capable of 
preventing data from ever being written to the bad sector again. Such errors are 
corrected with extremely high reliability, and the user can be assured that no 
data will be lost or corrupted. Once the corrective action has been taken (either 
automatically or through FTADMIN or FTREMOTE), the user need do nothing 
else. 


There are a number of situations that may cause mirrored partitions to become 
slightly dissimilar. This is referred to as a cracked mirror. Some examples are: 


Powering off or restarting the system without first performing a proper 
shutdown 


+ Automatic execution of CHKDSK at system startup time by HPFS when a 
dirty volume is detected in the system 
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* Accessing files on a mirrored volume when the FT driver has not been 
loaded, as may be the case after an IPL from diskette or another operating 
system 


None of the above are serious problems. The situation is normally detected by 
FTMONIT at the next IPL or during a verify operation. Verify will nearly always 
correct the errors by resynchronizing disk sectors that are not the same on both 
partitions. 


Persistent Failures 
While occasional failures in disk blocks are usually not a problem, repeated 
failures can indicate a disk may fail completely. The administrator may note the 
problem by a large number of read or write failures (usually recovered) on one 
partition of a mirrored drive. 


Alternatively, DISKFT may elect to shut down (partially or completely) one 
partition of a mirrored drive on which an unacceptable error rate is occurring. 


Total Disk Failure 


If a physical disk fails completely, the user has no time to prepare for the failure. 
In general, a single disk failing will never cause loss of data on mirrored drives. 
Different recovery steps are necessary depending on whether or not the IPL 
volume is lost. Consider the following: 


If the IPL drive is not lost, first install a replacement disk. Then use 
FTSETUP or FTREMOTE to recover and remirror all secondary partitions and 
to remirror all partitions that have lost their secondaries. 


If the IPL drive is lost, then a restart of the workstation from diskette may be 
necessary. An IPL from diskette will only allow the user to see primary 
partitions of mirrored drives. Therefore, if a mirrored drive lost its primary 
partition when the disk failed, it will not be visible. It is also not added to the 
Boot Manager menu (it is not visible, so no drive letter is assigned to it). In 
addition, any mirrored drive accessed when the FT driver is not loaded will 
end up cracked and will need to be verified by FTADMIN. 


See “Total Failure of Non-IPL Drive” and the section “Preparation for Boot Drive 
Recovery” on page 260 for recovery methods. 


Total Failure of Non-IPL Drive 


Data on the mirrored partition will be safe. The recovery procedure is fairly 
simple: 


1. Replace the failed disk. 
2. Use FTSETUP or FTREMOTE to recover: 
+ A detached secondary (the FT primary failed) 
- Select Recover and make it the secondary of a mirror 
+ A primary without any secondary (the FT secondary failed) 


- Select Mirror the drive 
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Preparation for Boot Drive Recovery 
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Unfortunately, as you might expect, recovering from a failed boot partition is 
somewhat more complicated. There are a number of activities that need to be 
completed before the disk fails: 


+ Create HPFS386 boot diskettes from a copy of the OS/2 installation diskette 


and diskette 1 for the level of OS/2 on your FT system. See “HPFS386 Boot 
Diskettes” on page 216 for more information. For OS/2 LAN Server 3.0, it 
may be necessary to edit the CONFIG.SYS file on your new diskette 1, to 
change the LIBPATH statement from: 





LIBPATH=A: \; 





to: 











LIBPATH=.;A:\; 





This means that the current directory as well as the A: root is searched 
when OS/2 is searching for DLLs to load. This is necessary since we will be 
using FDISK and FTREMOTE in recovering the IPL drive, and all of the files 
needed will be too big to fit on a single 1.44MB floppy disk. 


Note: In OS/2 LAN Server 4.0 FTREMOTE has been altered to remove its 
dependence on Presentation Manager DLLs. This means that many DLLs 
that previously had to be accessible are no longer required. The following 
step regarding compressing the DLLs to later load them onto a hard disk is 
therefore not needed for OS/2 LAN Server 4.0, and any reference to the 
compressed files can be ignored in the subsequent example. A third diskette 
can be used to hold the files instead. The list of files required for recovery is 
shown in Figure 146 on page 263. 


+ For OS/2 LAN Server 3.0, there are approximately 2.5MB of files required in 


the recovery process. It is possible to manually copy the list of files on to 
two diskettes, then later copy all of these files to the fixed disk, but a better 
alternative is to use a compression utility such as PKZIP2 to compress these 
files onto one diskette. We have provided a REXX CMD example to run the 
PKZIP2 commands. This allows you to simply rerun the CMD file when your 
system is updated with new files from ServicePaks or CSDs. The sample 
REXxX file, ZIPFT.CMD in Figure 145 on page 261 shows how to: 


1. Compress the 2.5MB of files required to 1.2MB 


2. Produce a self-extracting executable, so that when recovering these files, 
the PKUNZIP utility does not need to be used 


Figure 146 on page 263 lists the files required if you wish to copy them to a 
diskette using another method. 
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/* rexx command file to produce self-extracting zip file for */ 


/* LAN Server 3.0 Fault Tolerance recovery of boot drive 


"@echo off' 


ADDR: 





ESS CMD 


/* change the following paths as necessary */ 

/* for your machine environment */ 

/* these are the source libraries for what will */ 
/* copied onto the disks */ 


os2dl1l = 'C:\OS2\DLL\' 

muglibdll = 'C:\MUGLIB\DLL\' 
ibmlannetprog = 'C:\IBMLAN\NETPROG\' 
ibmlannetlib = 'C:\IBMLAN\NETLIB\' 


os2 = 








'C:\OS2\' 


/* filename of final zip file */ 
zipfile = 'FTFILES' 





/* pkunzip command to produce zip file */ 
zipcom = 'PKZIP2 -a' 


/* load rexx dll, if not loaded previously */ 


call RxFuncAdd 'SysLoadFuncs', 'RexxUtil', 'SysLoadFuncs' 
call SysLoadFuncs 


call SysCls 


say 
say 
say 
say 
say 
say 
say 
say 


This utility will create a self-extracting zip file' 
which contains all the necessary files to recover' 
the server boot drive using FTREMOTE.' 














This utility needs approx 2.5 Mb free space available.' 
for temporary files, and produces the file' zipfile || '. 





/* zip files from \OS2\DLL directory */ 




















zipcom zipfile os2dl1l1 "DISPLAY.DLL' 
zipcom zipfile os2dl1l1 "DOSCALL1.DLL' 
zipcom zipfile os2dl1l1 'MSG.DLL' 
zipcom zipfile os2dl1l1 'NLS.DLL' 
zipcom zipfile os2dl1l1 'PMGPI.DLL' 
zipcom zipfile os2dl1l1 'PMGRE.DLL' 
zipcom zipfile os2d11 "PMSHAPI.DLL' 
zipcom zipfile os2dl1l 'PMSHLTKT.DLL' 
zipcom zipfile os2d1l1 "PMSPL.DLL' 
zipcom zipfile os2d11 'PMWIN.DLL' 
zipcom zipfile os2dl1l1 'SPL1B.DLL' 
zipcom zipfile os2dl1l1 "NAMPIPES.DLL' 





Figure 145 (Part 1 of 2). ZIPFT.CMD for OS/2 LAN Server 3.0 FTREMOTE Recovery 
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/* zip files from \MUGLIB\DLL directory */ 














zipcom zipfile muglibdll 'NETAPI.DLL' 
/* remove the following line if LS3.0 ServicePak not installed */ 
/* since it is not part of the LS 3.0 GA package ee 
zipcom zipfile muglibdll "NETAPI32.DLL' 
zipcom zipfile muglibdll 'NETOEM.DLL' 
zipcom zipfile muglibdll 'NETSPOOL.DLL' 
zipcom zipfile muglibdll "MAILSLOT.DLL' 











/* zip files from \IBMLAN\NETPROG directory */ 
zipcom zipfile ibmlannetprog || 'FTREMOTE.EXE' 




















/* zip files from \IBMLAN\NETLIB directory */ 
zipcom zipfile ibmlannetlib || 'FT.DLL' 





/* zip files from \OS2 directory */ 
zipcom zipfile os2 || 'FDISK.COM' 








'zip2exe' zipfile 
say 'Deleting temporary ZIP file .....' 
re = SysFileDelete(zipfile || '.ZIP') 


call SysCls 














say‘ ' 
say 'File has been created. Copy file' zipfile || '.EXE' 
say 'to floppy disk to enable recovery of boot drive.' 
exit 








Figure 145 (Part 2 of 2). ZIPFT.CMD for OS/2 LAN Server 3.0 FTREMOTE Recovery 





-—— PKZIP for IBM Employees 


Note: IBM employees using the PKZIBM2 package on the OS2TOOLS 
tools disk need to create a file called PKSFX2.PRG, which is not part of 
the current package. The simplest way to do this is copy it from the 
existing file PKSFX.PRG. This file is required in the ZIP2EXE program to 
create the self-extracting executable. 
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Files from \OS2\DLL 
DISPLAY .DLL 
DOSCALL1.DLL Highlighted files are not required 
MSG.DLL by LAN Server 4.0 
NLS .DLL 
PMGPI.DLL 
PMGRE .DLL 
PMSHAPI.DLL 
PMSHLTKT .DLL 
PMSPL.DLL 
PMWIN.DLL 
SPL1B.DLL 

NAMPIPES.DLL 




















Files from \MUGLIB\DLL 
NETAPI.DLL 

NETAPI32.DLL (Only Server versions above the 3.0 ServicePak |IPx7005 
N. 

NI 






































ETOEM. DLL 
ETSPOOL. DLL 
MATLSLOT. DLL 
































Files from \IBMLAN\NETPROG 
FTREMOTE . EXE 
































File from \IBMLAN\NETLIB 
FT.DLL 


























Files from \OS2 
FDISK.COM 




















Figure 146. Files Needed for Recovery of IPL Drive by LAN Server 3.0 and 4.0. Note that 
highlighted files are not required by FTREMOTE in LAN Server 4.0. 


* Determine the locations of the mirrored disks. This can be done by either 
running FTSETUP or FTREMOTE. 


If using FTSETUP, highlight the IPL drive as shown in Figure 147. 


ba, bauit: Tolerance Setup 
i Gptions Hel 


irrorel 
Not mirrered 
Cannet mirror 
SPARE_DISK Cannot mirror 








Figure 147. FTSETUP - Selection of IPL Drive for Action 


Then, select the Drive menu, and select the Details option as shown in 
Figure 148 on page 264. 
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Se haut: Tolerance Setup 


Gptions Help 
Volume 
Mirror... 


SPARE_DISK 


Figure 148. FTSETUP - Selection of IPL Drive Details 


The drive information is then displayed, as in Figure 149. In this example, 
the location of the secondary drive, as required in the FTREMOTE response 
file, is 2:6 for recovery, where 2 is the drive number, and 6 is the cylinder 


number. 


Status 
Mirrored 

Not mirrered 
Cannet mirror 
Cannet mirror 








“ Fault Tolerance Setup 















Drive letter: 
IPL drive letter: 
Volume name: 

Status: 

Drive format: 

Drive size (megabytes): 







Primary partition disk: 
Primary starting cylinder: 





Secondary partition disk: 
Secondary starting cylinder: 

















Figure 149. FTSETUP - IPL Drive Details 


If using FTREMOTE to determine the location of the secondary drive, create a 


response file containing the following: 





Current <> 


Figure 150. NULL.RSP Response File for FTREMOTE 


If this file is called, say NULL.RSP, invoke FTREMOTE with the command line: 





FTREMOTE /R:NULL.RSP 











The FTSTATUS.LOG file will then contain the current Fault Tolerance 


configuration, as shown in Figure 151 on page 265. 
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Fault Tolerance Utility FTREMOTE - Version 4.0 


























Drive Location Status 
Cc cle (2:6) Mirrored 
D 1:101 (2:106) Mirrored 
E Tetd5 Not mirrored 
F 1:201 Cannot mirror 
G 2 Cannot mirror 








The total available space for mirroring is 149 MB. 
The largest contiguous space is 149 MB. 

















Drive Error Information 








There are no errors on drive 
There are no errors on drive 
There are no errors on drive 
There are no errors on drive 
There are no errors on drive 





QymAua 





Figure 151. FTSTATUS.LOG Output from NULL.RSP Response File 


This shows that the location of the secondary mirror for drive C:, as in the 
parenthesis in Figure 151, is again 2:6 - that is, drive 2, cylinder 6. 


Since we know the Fault Tolerance configuration, we can create the 
FTREMOTE response file now to save time later, when we need to actually 
perform the recovery. The FT.RSP file below is the format required to 
perform recovery of the IPL drive in this example. If you create this 
response file now, you can copy it onto your disk(s) used for the files needed 
for FTREMOTE and FDISK. 








COMMANDS < 
recover loc=2:6 secondary > 

















Figure 152. FT.RSP Response File for FTREMOTE 


If using OS/2 LAN Server 3.0, you will need to ensure that a logical partition 
exists on the secondary drive with space available for the files needed to run 
FTREMOTE and FDISK as described above. They will be copied onto this 
drive when recovering the IPL drive. 


If the server has a system partition containing the reference diskette 
information (for example, IBM PS/2 Model 95), this system partition should 
be backed up to diskette. 


This completes the tasks necessary before a failure takes place. Keep the 
diskettes created in a safe place and run through the above checks and changes 
each time alterations are made to the server, for example, if disks are added or 
if OS/2 or LAN Server is upgraded. 
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This section describes an example of the boot drive recovery scenario. 


Note: It is mandatory to know the cylinder location of each FT primary and 
secondary partition before the recovery situation occurs. Use either FTSETUP or 
FTREMOTE as described in the previous section to make a note of this 
information for the future recovery process. 


Before you start, as described in the previous procedure, you must have: 


HPFS386 bootable diskettes (note that these should be at the OS/2 and LAN 
Server level installed on the system being recovered) 


Copies of the files to run FDISK and FTREMOTE 

Backup of reference partition information (if required) 
The machine used for this test was an IBM PS/2 Model 95 running OS/2 2.1, and 
functioning as an additional server. The example was performed on OS/2 LAN 


Server 3.0 so we can describe the process for both 3.0 and 4.0. The disks were 
configured as follows: 




















Drive Type Size (MB) Notes 

Boot manager 

C: IPL drive - 
primary partition 
of mirror 

D: Primary partition 
of mirror 

E: Unmirrored 

F: 

Table 13. FT Boot Drive Recovery Scenario - Disk 1 

Drive Size (MB) Notes 

None Freespace 

G: This drive will be 
used in the 
recovery process 
as the location 
where the 
necessary files 
will be copied to 

None C: secondary 
mirror - will be 
used to recover 
IPL drive 

None D: secondary 
mirror 

None Freespace 











Table 14. FT Boot Drive Recovery Scenario - Disk 2 


Note: In the preceding tables, the HPFS drives are all HPFS386 drives. The 
secondary mirrored drives are shown in FDISK as having a file system type of 
87. 
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To attempt to simulate a real-life environment, the server was running and not 
shutdown before the power was turned off. The following is the procedure: 


1. Replace disk 1. Depending on whether this is a new drive from the 
manufacturer or has been used before, you may need to perform a low-level 
format on the disk before fault tolerance recovery will work. In our testing, 
we found that when using a disk that had been used before, a low-level 
format was advisable. Otherwise, the IPL drive would seemingly recover 
OK, but we found the machine would hang and not boot at all from the new 
fixed disk. 


2. If the server has a built-in system partition, this will need to be restored from 
the backup diskette onto the new fixed disk. 


3. Boot the machine from floppy disks, using the HPFS386 boot diskettes, 
created following the “Preparation for Boot Drive Recovery” on page 260 
instructions. During this boot process, it is likely that you may see the 
message: 


BSHO005: A good CONFIG.SYS cannot be found on your workstation. 





Booting is continuing. 


This message be can ignored. Booting will continue until the [A: ] prompt 
appears. 


4. If using OS/2 LAN Server 3.0, change the default drive to the one that will be 
used to copy the FTREMOTE files to. In our case, our original drive G: has 
now become drive C: when disk 1 was replaced, since drives C: to F: do not 
currently exist. If using the zipped files method, insert the disk that contains 
the zipped files, and type: 





A: FTFILES 











Otherwise copy the required files to the drive manually. 
5. Run FDISK to add Boot Manager to the new drive 1. 


6. Ensure your FTREMOTE response file is accessible to FTREMOTE. If using 
the hard drive, copy it into the current directory or else ensure it is on your 
FTREMOTE.EXE diskette. (Refer to Figure 151 on page 265 and Figure 152 
on page 265 for details on how to create the correct response file). 

7. Run FTREMOTE to recover the IPL drive. On the command line, type: 


FTREMOTE /R:FT.RSP 














This can take quite a while, and the program will not issue any messages to 
the screen regarding whether the recovery was successful or not - only to 
the history log file. 


8. The output from FTREMOTE needs to be verified to check that the restore 
was successful. By default, FTREMOTE writes to FTHIST.LOG and 
FTSTATUS.LOG. An example of the contents of FTHIST.LOG are displayed in 
Figure 153 on page 268. 
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Fault Tolerance Utility FTR 


















































EMOT 


E - Version 4.0 








FTREMOTE is loading the file ft.rsp into memory. 
FTREMOTE has successfully loaded the file ft.rsp into memory. 


FTREMOTE is processing the COMMANDS section of ft.rsp. 





FTREMOTE is recovering the drive at location 2:6. 
Status: The drive at location 2:6 has been recovered 
and mirrored as drive C. 


FTREMOTE has ended successfully. 





Figure 153. FTHIST.LOG Output from Run of FTREMOTE 


An example of the contents of FTHIST.LOG are displayed in Figure 154. 
































Fault Tolerance Utility FTREMOTE - Version 4.0 
Drive Location Status 

Cc 1:1 (2:6) Mirrored 

D 2:1 Not mirrored 

E 2:106 Not mirrored 

? 2:156 Detached 





The total available space for mirroring is 300 MB. 
The largest contiguous space is 201 MB. 








Error information will not be available until after IPL. 


Figure 154. FTSTATUS.LOG Output from Run of FTREMOTE 


9. Run FDISK again and add the newly recovered IPL drive to the Boot 


Manager menu. 


10. The server should now be rebooted. 
11. FTADMIN should then be run to verify the IPL drive 


12. Next, we need to recover the remaining disks from the secondary partition in 
FTSETUP. When you enter FTSETUP, the detached secondary has a ? in the 
drive name, as well as the Detached status. 


Highlight the detached secondary drive, and select the Drive menu option. 
Then select Recover secondary, which makes the drive the secondary of a 
mirror, as shown in Figure 155 on page 269. 
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the primary of a 
Make the drive the secondary ot a mirror... 











Figure 155. FTSETUP - Recovery of Detached Primary Drive 


Once the option is selected, a message box will be displayed stating that the 
recovery and mirroring are complete. 

Now that the drive has been recovered, press the F3 key to exit FTSETUP, 
and the next message box in Figure 156 is displayed: 





: Part 5 
ot Bie BRGRtL miections thalaiieet Ane - aut HErAnCE Battiior 





















Figure 156. FTSETUP - Save Partition Changes 


If you elect to save the changes, the following message is displayed, and the 
data from the detached secondary partition is copied across to the newly 
created primary partition. 





Figure 157. FTSETUP - Copying Data 


When all of the data is copied, FTSETUP is finished. Since the drive letters 
have now changed, the following message box in Figure 158 on page 270 is 
displayed. You should then shut down the server. 
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tab You ms 4 OE 


iA 





Figure 158. FTSETUP - Exit 
13. Reboot the server. Recovery is now complete. 


As a guideline, this test of the recovery process from the replacing of the disk to 
the last IPL of the server was complete in 35 minutes. 





Additional Hints and Tips for Recovery 
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Here are some recommendations, that resulted from the tests performed: 


Don't expect to get a bootable partition after recovering a secondary 

detached partition if this secondary partition was the mirrored IPL drive, and 

if you didn't specify the secondary parameter at the RECOVER command in the 
FTREMOTE response file. See the following two examples. 














COMMANDS < 














RECOVER loc=xx:yyy > 








Figure 159. FTREMOTE Response Sample - Recover as a Non-FT Drive 


COMMANDS < 
RECOVER loc=xx:yyy primary > 




















Figure 160. FTREMOTE Response Sample - Recover as a FT Primary Drive 


The content of a mirrored partition is exactly the same as in the original boot 
drive. However, the settings of the OS/2 2.x Desktop will still have the drive 
specification equal to the original IPL drive. If you recover this IPL partition 
with the option primary or no parameter with the RECOVER command, the 
recovered partition will become a non-FT drive and will take another drive 
letter after the next IPL. Depending on the drive location within the physical 
disks, the drive letters might be changed after the unmirror or recover 
operation. Then, several problems will happen: 


- Errors in CONFIG.SYS (IPL fails) 














- Settings of the Desktop objects will not be accurate 
- LAN definitions in ALIAS will no longer be correct 


In brief, all references to the “old” IPL drive will no longer be correct. The 
following are examples of how the recovery results are different. 


1. Look at the drive letters and FT drives in the following figure. 
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Disk1 Disk 2 











Cc OS/2 2.x boot drive ae E 
E Ree a 
ee. ae Mirrored 
Cc (C' 
<>: Boot Manager Ae? 
Wh fe 





Figure 161. FT Drive Letters Before Failure 


2. Assuming Disk1 has a failure and Disk1 is replaced. Use the HPFS386 IPL 
diskette and use FTREMOTE with a proper response file. The Fault 
Tolerance recovery system will search the free space for the mirroring 
area. The following figure shows this. 


Disk1 Disk 2 


(E) 


Detached 
Secondary 























Figure 162. FT Recovery to Free Disk Space 


3. If you specify neither primary nor secondary in a RECOVER command 
parameter, the detached secondary partition will become a non-FT drive. 
The following figure assumes C: is created. 





























Disk1 Disk 2 
i. 
Rog = 2 eH a: 
FTREMOTE response file [Pie | 
c COMMANDS < D 
ee RECOVER LOG=2:120 > 
ESA Boe 
a 
SS Sa oyLia 
Recovered 
Sc bee OS/2 2.x boot drive E 
a as Non-FT drive eet 5 = 35 
Potea Ss see 
“Ss Boot Manager 





Figure 163. FT Recovery Creating Non-FT Drive 
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4. lf you specify primary in a RECOVER command parameter, FT recovery 
will use the first free disk space in Disk1 as an FT secondary partition 
space and copy all the drive contents of the detached secondary 
partition. Then the OS/2 2.x boot drive will have a drive letter other than 
C:, as shown in the following figure. 

















Disk1 Disk 2 
ae FTREMOTE responses file 
EE Oe SRS 
FT secondary | COMMANDS < od 
RECOVER LOG=2:120 PRIMARY (D) 
ioe. ee 
a ee 
Mir, @ CYL120 eo 
tOting Co 4B) 
Saw ee Recovered 


: OS/2 2.x 
KS FT primary : 
“drive 


—~_-"_ Boot Manager 

















Figure 164. FT Detached Secondary is Recovered as Primary 


5. The right recovery process is to use the secondary option in a RECOVER 
command. This will cause FT recovery to use the first free space in Disk1 
as an FT primary partition. After a copy is done from the detached 
secondary (mirrored C:), C: drive will become active as an FT primary 
partition. There is no drive letter change in this case. 








Disk1 Disk 2 


es FTREMOTE response file 




















COMMANDS < Ca 
Free space | RECOVER Loc=2:120 SECONDARY > (E) 
A ge 
pe Recove, ies ae 
a, 
CYL 120 ae 

SS ee Mirrored 
oo 
foe 5 ee ee On ( On) 








~~ Boot Manager 





Figure 165. FT Detached Secondary is Recovered as Secondary 


In the case of a replacement of a failed disk, you can rearrange your initial 
partitions. In this case you must know the layout of your disks exactly, and 
where partitions (primary or secondary) exist on your disks. Remember, a 
drive letter will be changed if you delete or add partitions within existing 
partitions. 


Note: However, the drive's volume label will not be changed, unlike the 
drive letters. 
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Summary 


With OS/2 LAN Server Advanced, Fault Tolerance will protect the entire system 
against most disk errors both minor and major. Fault tolerance is only a part of 
systems management and should be considered alongside regular backups and 
other methods of ensuring reliability, serviceability and availability. 


Use FTADMIN regularly to verify your drives. 
Draw a map of your disks in the system that shows the layout of your logical 


drives. This could be useful in case of recovery. To do this you can run 
FTREMOTE with no parameters in the Current section of the response file. 
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Chapter 12. Backup Domain Controller 


The purpose of this chapter is to describe the implementation of the Backup 
Domain Controller in OS/2 LAN Server. While the Backup Domain Controller 
facility has been available since release 2.0, it has received little explanation in 
the past. This description covers the backup function and enhancements made, 
in each release from OS/2 LAN Server 2.0 to OS/2 LAN Server 4.0. The main 
contribution of OS/2 LAN Server 4.0 to the Backup Domain Controller function is 
the roll-up of all changes and enhancements, providing a complete backup 
package. 


The ability to duplicate the role of the domain controller to other servers in the 
domain provides very high levels of reliability, availability and servicability 

(RAS). The backup domain controller can also spread the workload of the actual 
domain controller (often referred to as the Primary DC or just the DC), improving 
response times particularly during the logon process. 





Introduction to the Domain Controller Function 


The Domain Controller (DC) is a special server that implements the single 
system image concept of a domain through the use of extra server functions. The 
SSI concept allows a user to access resources from any server in the LAN 
without necessarily being aware of which server they may reside on. There can 
only be one DC for each domain although any number of domains can exist in 
the same physical LAN. 


The DC uses the Graphical User Interface (GUI), User Profile Management 
(UPM), command line and API functions to maintain a list of user and group 
names in the NET.ACC file. These entries define a user name to the domain and 
determine that user's overall ability to access resources in the domain. A 
workstation wishing to access resources within a domain must use a user name 
that exists in the NET.ACC file. The NETLOGON function running at each server 
duplicates this information from the DC and keeps a copy in that server's local 
NET.ACC file. 


The other main task of a DC is to maintain a Domain Control Database (DCDB) 
containing information about definitions of network resources that users might 
access. Included in the DCDB are user's automatic logon assignments, public 
applications definitions and the details of resources shared through aliases. 


Domain Logon Process 


© Copyright IBM Corp. 1995 


In order to access resources in the domain, the user name used by someone at 

a workstation needs to be verified against the NET.ACC user information to 

ensure the user has access to the requested resource. Since OS/2 LAN Server 

3.0, it has been possible to force this verification to take place at the time the 
resource is actually shared through the use of the IBMLAN.INI 
logonverification= parameter or through the /V: option of the logon command. 
However, to use facilities such as home directories, logon assignments, and 
public/network applications, a logon must be made and verified at the domain 

level (that is by a DC or backup DC). 
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When a user attempts to logon to the domain, a NetBIOS Datagram (broadcast to 
all system running NetBIOS) frame is sent. This frame includes the NetBIOS 
name of the domain to which the logon is being attempted. Every workstation 
running NetBIOS will review the frame and a domain controller recognizing the 
domain name will respond to it, establishing a session to perform the logon 
processes. 


If the DC is operative, the first stage of a domain logon (the user verification) will 
be handled. If no DC is operative, the requester will time out and tell the user 
that a domain controller could not be found. 


After the user verification, logon initiates a DCDB check for the user name that 
logged on to determine what other logon functions, such as logon assignments, 
should be performed. This step obviously requires the DCDB to be present at the 
DC. 


Implementing a Backup for the Domain Controller 


Because of the critical functions of the DC, it is essential to maintain a current 
backup of the important components of the domain controller. These are the 
NET.ACC file and the DCDB. In the event of a failure of the DC, those already 
logged on and using resources from servers other than the DC will continue to 
function. However, new logons and other facilities such as password changing 
will not be available. For this reason, it is important to consider the fastest 
possible way of returning the DC function to the domain after a DC failure. 


What is required is a two-part process. First, the backup is required to handle 
the verification of a user on the domain during logon to ensure correct access 
rights. The second requirement is the checking of the DCDB to provide items 
such as logon assignments to users during the logon. 


Note: There is an additional requirement in OS/2 LAN Server 4.0 if use is made 
of logon scripts (as specified for a user in the NET USER command). As scripts 
are not by default contained in the DCDB, they are not automatically replicated 
to backup domain controllers. You will need to manually copy them to all 
backups (either using the replicator, using an AT command or copying them to 
backup manually after changes) in order for the script to be run when a User ID 
is validated by a backup DC. A preferred strategy is to locate the scripts in the 
DCDB by altering the path through the Scripts parameter in the NETLOGON 
section of the IBMLAN.INI. 


Providing a Backup for the Domain Logon 


276 


OS/2 LAN Server V2.0 introduced a NET ACCOUNTS server role type of BACKUP. 
This role makes any server perform the DC function of verifying domain logons 
from users. 


The handling of a domain logon function at a backup DC is possible because of 
NETLOGON copying the user and group information (in the NET.ACC) required to 
do this to every server. No additional setting up of the backup DC server is 
required. 


The default configuration, since OS/2 LAN Server 2.0, is such that the logon is 
handled by whichever DC or backup responds first. This balances the workload 
of logons and provides the fastest possible domain logon response time. 
Whether the logon is handled in this way is determined for each user name in 
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the user's settings and is set by the NET USER command preferred server option 
/LOGONSERVER. There are three possible modes of operation. Note that this switch 
was not documented in the manuals for OS/2 LAN Server 3.0, but it is accepted 

by the 3.0 NET USER command. The display of a user with NET USER username 
includes a field which states the users Domain Controller (in version 3.0) or 
Preferred Logon Server (in version 4.0). This is the field set by this switch. The 
switch options and effects are as follows: 


+ /LOGONSERVER:\" This option is displayed in the NET USER output as Any. 
When specified in this way, the logon initiation broadcast sent by a 
workstation will be handled by the first DC or backup DC to respond from the 
requested logon domain. This is the default selected when the user is 
defined from UPM or the command line. From the GUI, the new user will take 
on the same attributes as that used to create it (for example from the 
template user or from a copied user). 





























+ /LOGONSERVER:\\servername When a server's machine name is specified 
in this way, the user will be logged on to the domain by the specified server. 
If there is no response from this server after three attempts, the first to 
respond to another backup or the DC will handle the logon. This is displayed 
in NET USER output as the \\servername. 


+ /LOGONSERVER:"" Setting the logon server name to null ("") indicates that 
the preferred logon server is the primary (that is, the true) domain controller. 
A backup DC will not respond to the logon attempt until three tries to logon 
at the DC have gone without response. This setting would reduce the load 
balancing effect of the default but means that unless the primary DC is very 
slow to respond the user will always be verified by the primary DC. This 
option displays Domain Controller from the NET USER output. 





Note: Earlier versions of OS/2 LAN Server may have the NULL setting as the 
default for a user. If you have upgraded the LAN through each release of LAN 
Server from 1.x, check the Domain Controller/Preferred Logon Server field with 
the NET USER command. You may wish to alter this for each user to "\\*" to 
make the first to respond handle the logon rather than trying three times at the 
primary DC. 


Providing a Backup for DCDB Facilites 
As logging on to the domain is only part of the story, consideration also has to 
be given to the duplication of the DCDB on a backup DC. With OS/2 LAN Server 
2.0, the DCDB had to be copied to the backup using, for example, XCOPYs at 
regular intervals or by using the Replicator service. 


With OS/2 LAN Server 2.0, in the event of a DC failure, logons will continue to be 
managed by a backup DC. Facilities enabled through the use of a DCDB, such as 
logon assignments, are not automatically handled by backup DCs in OS/2 LAN 
Server 2.0 until the role of the backup is changed to Primary as follows: 


NET STOP NETLOGON 
NET ACCOUNTS /ROLE: PRIMARY 
NET START NETLOGON 


























Of course, any sessions still active at the DC at the time of a DC failure will be 
disconnected, and the resources that physically reside there will not be 
accessible, a good reason for keeping the domain controller separate from file 
and printer services. 
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Before OS/2 LAN Server 3.0 level IPx7045, OS/2 requesters will not have their 
public applications folder appearing on the Desktop if the logon is validated by a 
backup because they always attempted to allocate these resources via the 
primary DC's DCDB. Also DOS LAN Requesters need to be at the IPx7045 level 
or above to allow them to logon to backups. 


With OS/2 LAN Server 3.0 and 4.0, if the DC fails, everything should continue to 
operate normally for all requesters from the backup DC. Users can continue to 
log on and off the domain and access resources as they would before the DC 
failed. If a logon has been validated by a backup DC, the user will receive a 
message to that effect. If a logon has been validated by a backup DC, some 
following DC functions will be sent to the logon server. Others will still attempt 
to be made at the primary DC to ensure that, whenever possible, the most 
up-to-date version of the DCDB is used. 


The DCDB should not be updated while the backup is serving the LAN because 
these will be lost when the primary is brought back online. Most requests for 
changes, such as password changes, will be refused while the DC functions are 
being handled by a server in the role of Backup. 





The NET STOP NETLOGON, NET ACCOUNTS /ROLE: PRIMARY, NET START NETLOGON 
sequence will change the backup role to that of primary and therefore allow it to 

continue as a fully functional DC. Any DCDB changes could then be copied back 

to the real DC if it were to come back into the domain as the Primary. 


























Either XCOPY or the DCDBREPL service, new in OS/2 LAN Server 3.0, can be 
used to copy the DCDB from the DC to backup DCs. DCDBREPL is a separate 
service to the Replicator service although it works in a very similar way. 
DCDBREPL will copy the entire DCDB subdirectory structure (excluding the 
IMAGES subdirectory used for Remote IPL) to the designated backup DC 
importers. It is important to check that the REPL.INI has been placed in every 
subdirectory below DCDB in the DC's IBMLAN\DCDB path. There must also be 
sufficient room for a second copy of the largest DCDB subdirectory on the 
importer because the DCDBREPL service creates a backup of each directory tree 
before deleting the original. As long as all directories under \IBMLAN\DCDB 
contain OK.RPS$, the backup should function correctly. 


Without the DCDB on the backup (that is if it has not been replicated), only the 
logon will succeed, and there have been problems for DLRs where a backup DC 
exists that does not contain a backup of the DCDB. The recommendation is, 
therefore, to have the DCDB backed up to every backup DC in the domain. 
Multiple backup DCs can be used to help spread the logon load. 


From OS/2 LAN Server 3.0, the option to configure a server as a backup DC is 
given during the installation process. If this option is taken, the role will be 
backup and the DCDBREPL service is installed and started automatically by 
default. The DCDBREPL service is also automatically installed and started on the 
DC. If there are no backup DCs, the service can be removed from the primary 
DC. 


Remember that for all components in the LAN to function correctly with the 
backup role, there were code changes after the initial release of OS/2 LAN 
Server 3.0. Ensure that all servers and requesters are either installed from 
OS/2 LAN Server 4.0 or at OS/2 LAN Server level IPx7045 or higher. 
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Setting Up a Backup Domain Controller 


NETLOGON must still be installed and running at the proposed backup DC server 
(this is installed and run by default). 


The DCDBREPL function is a subset of the Replicator service and is operated 
completely independently of it. Both can reside and function independently of 
each other. Because DCDBREPL is optimized for DCDB replication, the following 
parameters are set by default: 


+ The import and export paths are set to d:IBMLAN\DCDB (where d: is the 
drive on which LAN Server is installed). 


+ The import list, which is all servers in the role of Backup. 


Note that only the primary DC will be an exporter for DCDBREPL, and only 
servers with the role of Backup will be importers. 


Installing a Backup Domain Controller 


A primary or Backup domain controller can continue to function in every way as 
another server on the LAN, providing file, printer and other resources; however, 
it is recommended that at least the primary DC be dedicated to the DC function 
to reduce the impact of a DC failure. 


During installation of the server, selecting a Server Type of Backup Domain 
Controller (see Figure 166) will set the NET ACCOUNTS role to Backup. The 
DCDBREPL service components are also automatically installed during LAN 
Server installation if the Server Type of Domain Controller or Backup Domain 
Controller is selected. To install this service on an additional server, the 
installation program should be run. Select the role of backup DC and the correct 
files will be installed. 
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Figure 166. Backup DC - Selecting Server Type During LAN Server Installation 








Use NET ACCOUNTS /ROLE:MEMBER and NET ACCOUNTS /ROLE: BACKUP to switch the logo 
handling function of the backup off and on if required. Use autostart of 

DCDBREPL in the srvservices of IBMLAN.INI. Start and stop of the replication 

can be done manually with NET START DCDBREPL and NET STOP DCDBREPL or through 

the defined servers administration functions of the GUI. 
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DCDB Replicator Restrictions 


The following restrictions apply to the use of the DCDB Replicator: 


* The replication function can copy up to a maximum of 1000 files within any 
one subdirectory. This means that if you have more than 1000 users defined 
in your LAN (NET.ACC allows up to 8192 to be defined), replication will not 
be a complete solution to backing up the DC because only the first 1000 files 
will be replicated. Other methods (such as XCOPY in an AT command) will 
need to be employed. 


+ The export is confined to the backup DCs in the exporters domain. 


If the import path is accessed at the importer, the current replication will fail. 
NO_SYNC.RPS will appear in the top directory (below IBMLAN\DCDB) of the 
offending path, and the replication will be retried at the next sync interval. 


If user logon is performed by a backup DC, modifications of passwords and 
domain definitions must still be performed by the machine with the role of 
primary. This means that passwords, logon assignments and so on cannot 
be changed until either the DC is operational or a backup has its role 
changed to primary. 


Considerations for Setting Up the DCDB Replicator 
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The full steps for setting up the DCDB Replicator service are in the Network 
Administrator Reference Volume 3: Network Administrator Tasks. This section 
details important points to note when setting up this service. 


REPL.INI: The ASCII file REPL.INI must be in each subdirectory below the 
IBMLAN\DCDB subdirectory (excluding IMAGES). The extent parameter specifes 
whether the whole tree is checked for changes or just files in the top 

subdirectory. This should always be set to tree for DCDB replication. The 
integrity parameter specifies whether the whole tree or individual files have to 
be stable for the guardtime specified in IBMLAN.INI before a changed file is 
replicated. If many changes are made to the DCDB, setting this to tree could 
mean that parts of the DCDB are not replicated for long periods of time. This is 
especially true in a DOS user environment where logging on involves changes to 
the DCDB every time. The recommended setting is therefore file. 


DCDBREPL User ID: tryuser in IBMLAN.INI states whether the replicator will use 
a logged on user to connect to the domain controller to read updates from the 
export path. If this is set to yes, and if a user is logged on, they need the correct 
access rights for the replication to succeed (that is Read and Attributes rights to 
the whole IBMLAN DCDB tree of the primary DC). If tryuser is set to no, the 
replicator will not attempt any updates while a user is logged on. 


Either way, the replicator will use the user ID and password specified in the 
DCDBREPL section of the IBMLAN.INI. If a user ID is not specified for the DCDB 
replicator service, the server will try to use its own machine name to perform the 
replication. This fails due to incorrect access rights. This means that unless a 

user ID is specified here, or a user with the correct access is logged on and 
tryuser=yes, the replication will fail and NO_SYNC.RPS will appear in the DCDB 
subdirectories. If the primary DC cannot be contacted at all, NO_LMASTR.RPS 
appears in the backup DCDB directories. This would suggest the DC is down or 

a serious configuration error. 


This can present something of a security exposure in sites where the backup DC 
cannot be kept in a secure location (for example locked away in a room) 
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because a User ID and password giving access to the DCDB is available in an 
ASCII file (the IBMLAN.INI). Rather than using an administrator ID for this 
purpose, the recommendation is to use a user ID with the necessary attributes 
and read permissions. An additional safeguard was introduced in OS/2 LAN 
Server 3.0, in IBM APAR 1IC06847 (included in level IPx7045), which added a 
REPLINI utility that allowed this password to be stored in an encrypted form in 
the system's OS2.INI binary file, rather than the IBMLAN.INI. 


The one remaining problem, even with this method, is that if user passwords are 
set to expire (for example every 30 days), the DCDB replicator password will 
also need to be changed manually for the replicator to continue working. 





Sample Scenario for Backup Domain Controllers 


The domain concept was designed to group resources among sets of users, for 
example within a department. With companies increasingly running 
enterprise-wide applications on the LAN, there is now often a need to create 
single large domains. Since servers have been able to manage more sessions 
through multiple adapters, grouping users into larger domains has become 
feasible. 


For larger domains, the backup server facility obviously helps maintain a fast 
response to logon requests from the users. In multi-segment, single-domain 
LANs, the backup DC can be used to spread the logon administration of users 
around the segments reducing the level of broadcasts around segments and 
reducing the time otherwise taken to logon to the primary DC. 


In Figure 167 on page 282, each segment of a multi-segment LAN contains a 
backup DC, with the primary DC on the backbone. Users have the /LOGONSERVER 
set to their local backup making it the preferred server and reducing traffic 

across the segments to the backbone. If the local backup is busy, the primary 

will respond. 
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Figure 167. Backup DCs in a Multi-Segment LAN 














In this example, the user at workstation, WS1, has the /LOGONSERVER parameter 
naming the backup DC in the same segment - BUDC1. If for some reason this 
backup is unavailable, and assuming the bridge is not filtering out broadcasts, 

the logon from this workstation will be handled by either the primary DC (DC1) or 
BUDC2, whichever responds first. 


Note that this is just one possible layout. This concept could equally apply to 
other LAN, or even WAN, environments where OS/2 LAN Server can operate. 





The user at WS2 has \\* as the preferred server (/LOGONSERVER: \\*). The first DC 
or backup to respond will handle the logon. This will usually be BUDC2, but a 

slight delay in a response from BUDC2 may mean DC1 or BUDC1 will respond. 
Overall this might improve the logon response for a user when the DCs are 

busy, but there is likely to be more cross-segment traffic. 











lf a user at either workstation had two double quote marks as the preferred 
server (/LOGONSERVER: ""), then three attempts will be made to logon at the DC 
before any backup responds (that is, the DC becomes the preferred server). 














The domain controller function of handling logons is not particularly 
resource-hungry. If server functions such as file access, print spooling and RIPL 
are handled by dedicated servers, the DC and backups can quite reasonably be 
smaller, lower-cost systems. 


Note that one potential drawback of this type of scheme is the NETLOGON and 
DCDBREPL update traffic required from the primary DC to each backup DC. 
Fortunately, after the initial installation, most of the updates will be small 
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modifications and will generally involve less traffic than would occur if every 
user always logged on to the primary DC. 
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Chapter 13. Remote IPL 


This chapter will describe the Remote Initial Program Load (called RIPL or 
Remote IPL) feature of OS/2 LAN Server 4.0. Remote IPL services can be 
installed while installing OS/2 LAN Server 4.0 itself or in addition, when OS/2 
LAN Server 4.0 is installed already, by selecting the OS/2 LAN Services 
Installation/Configuration object from the IBM LAN Services folder. In both 
cases, at the Install and Remove window, select OS/2 Remote IPL Service and/or 
DOS Remote IPL Service to have Remote IPL services available for OS/2 and/or 
DOS, as shown in Figure 168. 
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Figure 168. LAN Server 4.0 Remote IPL Installation 
Note: For the information on DB2 CAE remote IPL, see Chapter 14, “Remote IPL 


Enablement of DB2 CAE for OS/2 V2.1” on page 339 and Chapter 15, “Remote 
IPL of DB2 CAE for Windows V2.1” on page 349. 
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Memory and Hard Disk Requirements 


The installation of a Remote IPL server requires slightly more memory and more 
hard disk space than a server that does not support Remote IPL. The following 
is a memory and hard disk space recommendation in addition to other 
requirements (for example, if CM/2, DB2/2, or others are installed on the server 
as well): 


Note: These numbers reflect our testing environment. 


Table 15. Additional Memory Requirements for Remote IPL Service 


Memory + 0.7 MB DOS Remote IPL service 
Os/2 + 0.8 MB OS/2 Remote IPL service 


Both DOS and OS/2 Remote IPL service 





Hard Disk Includes DOS LAN Support Program 1.36, Remote 
IPL copy of DOS LAN Services, IBM PC DOS 6.3, 


and one DOS image 





For each additional DOS image 





Includes DOS LAN Support Program 1.36Remote 
IPL copy of User Profile Management, LAPS, and 
OS/2 LAN Requester, a Remote IPL copy of OS/2 
2.11, and support for one Remote IPL workstation 





For each additional Remote IPL workstation 








Both 
DOS 
os/2 


An OS/2 Remote IPL requester that has been defined to swap remotely on the 
Remote IPL server is required to have at least 12MB of RAM installed. Local 
swapping (on the workstation's hard-disk) needs slightly less RAM. 


In this chapter, the following server and workstation names are used: 


OS2RIPLO1 - OS2RIPLO5 Remote IPL OS/2 clients 
RPLDOSO1 - RPLDOSO5 Remote IPL DOS clients 
ANYDOMO01 Domain Controller 

ANYSRVO1 Server with remote IPL feature 


for DOS and OS/2 


Understanding Remote IPL 
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Remote IPL is the process of downloading IPL files from a server to a 
workstation in order to start the workstation. 


You may use Remote IPL to start medialess workstations (workstations without 
disk drives) and workstations that do not have OS/2 LAN Requester or DOS LAN 
Services installed. 


OS/2 LAN Server 4.0 Remote IPL services can IPL the following, at defined 
remote IPL requesters: 
+ DOS 
OS/2 2.0 


OS/2 2.1 or OS/2 2.11 
OS/2 Warp, Version 3 (without WinOS/2) 
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Notes: 


1. To RIPL OS/2 Warp, Version 3 with WinOS/2, apply APAR 1C09214 (PTF 
IP08150). 


2. OS/2 LAN Server 4.0 does not support the Remote IPL of OS/2 1.3 
requesters. A LAN Server 2.0 machine with the capability to Remote-IPL 
OS/2 1.3 requesters on the domain does not maintain this capability when 
upgraded to OS/2 LAN Server 4.0 





Note concerning OS/2 2.1 vs. OS/2 2.11 


Since OS/2 2.11 is a refresh build of OS/2 2.1, only one of these two versions 
is supported for Remote IPL. OS/2 LAN Server 4.0 does not distinguish 
between OS/2 2.11 and OS/2 2.1. 





Workstations loaded by Remote IPL are called Remote IPL workstations. 
Remote IPL workstations can be started from IPL files on a server. When the 
workstation is turned on, the designated server sends IPL files to the 
workstation. 


Control Files for Remote IPL 
The Remote IPL process is controlled by these main files. 


The RPL.MAP Control File 

Required for both DOS and OS/2 Remote IPL, the RPL.MAP file contains 
requester and server records that define the behavior of the Remote IPL service 
for each DOS or OS/2 requester. 


Each Remote IPL requester must have its own entry pointing to a server record 
before Remote IPL can occur. There are several ways, described in this chapter, 
to create requester records. The Remote IPL requester definitions in the 
RPL.MAP file specify the name of the Remote IPL server to use and the 
parameters required to IPL that requester. 


The RPL.MAP file modified for DOS and OS/2 2.1 with IBM Token-Ring Adapter is 
shown in Figure 169 on page 289. Consider the overview tables, Table 16 and 
Table 17 on page 290, to understand the server and workstation record fields. 


Table 16 (Page 1 of 2). Description of the Server Record Fields 


Field Name / Value Description 
1 YYYYYYYYYYYYy This field consists of 12 y characters (12 bytes). 
2 XXXXXXXX.CNF This field specifies the boot block configuration file used to 


start a workstation. See “Boot Block Definition (.CNF) File” on 
page 293 for more details. 


3 3 or 0 This field specifies the number of retries in a given period that 
a requester with no specific entry in the RPL.MAP file must 
request IPL before a RPL.MAP entry containing a wildcard 
character (default boot) is used. If there is only one Remote 
IPL server, this value should be 0. Otherwise value must be 
non-zero so that every Remote IPL server has a chance to 
service the IPL request. 


4 10 This field specifies the time interval in seconds during which 
the number of unanswered IPL requests specified in field 3 
must be received before a default IPL configuration is used. 
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Field 
5 


10 
11 


12 


13 
14 








Name / Value 


Nor A 


IBMLAN$ or ~ 


DOS~IBM~ and 
others 


R_Dxxxx 
R_20_xxxx 
R_21_xxxx 
R_230_xxxx 





Table 16 (Page 2 of 2). Description of the Server Record Fields 


Description 


This field specifies whether the remote IPL server 
acknowledges each packet sent. The valid values are either A 
(Acknowledge) or N (Do not acknowledge). Usually N is 
specified since the setting A increases the traffic across the 
network. 


For DOS remote IPL, this field specifies the netname where 
the DOS images are located. The images are assumed to be 
in the IMBLAN DCDB IMAGES directory path from this 

share. For OS/2 Remote IPL, this field must contain a tilde (~) 
character. 


This field is used for a descriptive comment. This field is 
required when an OS/2 Remote IPL requester is running in a 
PC Network II or PC Network II/A network environment. 
OS2~PCNET indicates running in a PC Network environment, 
whereas OS2~PCNETA indicates PC Network/A. The GETRPL 
post-install utility uses this field also to enable and disable the 
server records correctly according to the adapter type of the 
remote boot server. Following naming conventions apply: 


* Token-Ring server records must include the string TOKEN. 

* Ethernet server records must include the string ETHER. 

* PC Network server records must include the string PCNET. 
This field is not used. It must contain one tilde (~) character. 
This field is not used. It must contain one tilde (~) character. 
This field must contain three commas (,,,). 


This field must contain a tilde (~) for OS/2. For DOS remote 
IPL, this field specifies the LASTDRIVE value. The default 
value is Z. 


This key field identifies a server record identifier. Each 
identical yyyyyyyyyyyy line must have a different value for 

this field. Field 12 must begin with R, which enables the 
record. For DOS server records use R_Dxxxx where xxxx can 
be any unique string. See “Understanding OS/2 Server 
Record Identifier’ on page 291 for OS/2 server records 
description. 


This field is not used. It must contain one tilde (~) character. 


This field is not used. It must contain one tilde (~) character. 


Note: Unused fields are retained for compatibility with previous versions of LAN 


Server. 


The following table shows the RPL.MAP file that was modified by the GETRPL 
utility for DOS and OS/2 2.1 with the IBM Token-Ring Adapter. 
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; server record fields: 
> 1 = yyyyyyyyyyyy 
2 = boot block configuration file (.cnf) 
3  =number of retries before default boot 
4 time window for retries (in seconds) 
5 = acknowledge (A,N) 
6 = loader parameters (~ for os2, image share name for dos) 
7  =descriptive comment 
; 89,=~ 
A 
B 
Cc 
D 


= workstation type; first letter is always R 


ES 

; server records 

syyyyyyyyyyyy dosnis.cnf 3 10 N IBMLAN$ DOS ~IBM~LANSTREAMER~MC~32~TOKEN~RING ~ ~ ,,,Z R_DTKLS ~ ~ 
syyyyyyyyyyyy dosnaae.cnf 3 10 N IBMLAN$ DOS ~IBM~LAN~ADAPTER/A~FOR~ETHERNET ~ ~ ,,, ZR_DETAAE ~ ~ 
syyyyyyyyyyyy dosn164.cnf 3 10 N IBMLAN$ DOS ~IBM~TOKEN~RING ~NETWORK~16/4~ADAPTER~Il ~ ~ ,,, Z R_DTK164 ~ ~ 
syyyyyyyyyyyy dosnwdp.cnf 3 10 N IBMLAN$ DOS~SMC~ETHERCARD~PLUS~ELITE16 ~ ~ ,,,Z R_DETWDP ~ ~ 

syyyyyyyyyyyy dosn3e3.cnf 3 10 N IBMLAN$ DOS~3COM~ETHERLINK~IIl~(3C509) ~ ~ ,,,Z R_DET3E3 ~ ~ 

syyyyyyyyyyyy dosn316.cnf 3 10 N IBMLAN$ DOS ~3COM~ETHERLINK~ 16 ~(3C507) ~ ~ ,,,Z R_DET316 ~ ~ 

syyyyyyyyyyyy dosnps2.cnf 3 10 N IBMLAN$ DOS~IBM~PS/2~ADAPTER~FOR~BNC/UTP~ETHERNET ~ ~ ,,,Z R_DETPS2 ~ ~ 
syyyyyyyyyyyy dosnlae.cnf 3 10 N IBMLAN$ DOS ~IBM~LAN~ADAPTER~FOR~ETHERNET ~ ~ ,,, Z R_DETLAE ~ ~ 


syyyyyyyyyyyy dosnd3em.cnf 3 10 N IBMLAN$ DOS~3COM~ETHERLINK~MC ~ ~ 


syyyyyyyyyyyy dosnd3ei.cnf 3 10 N IBMLAN$ DOS ~3COM~ETHERLINK~Il ~ ~ 


»» 2 R_D3CELNK_MC ~ ~ 
», 2 R_D3CELNK_II ~ ~ 


-yyyyyyyyyyyy dosndet.cnf 3 10 N IBMLAN$ DOS~IBM~ETHERNET~NDIS ~ ~ ,,, ZR_DET_NDIS ~ ~ 


yyyyyyyyyyyy dosndtr.cnf 3 10 N IBMLAN$ DOS~TOKEN~RING~NDIS ~ ~ ,,,Z R_DTK_NDIS ~ ~ 

syyyyyyyyyyyy dosbbet.cnf 3 10 N IBMLAN$ DOS ~IBM~ETHERNET ~-~,,ZR_DET ~ ~ 

syyyyyyyyyyyy dosbbpc.cnf 3 10 N IBMLAN$ DOS~PCNET ~-~,,ZR_DPC ~~ 

yyyyyyyyyyyy dosbbtr.cnf 3 10 N IBMLAN$ DOS~TOKEN~RING ~~,,2ZR_DTK ~~ 

syyyyyyyyyyyy os220et.cnf 310 N ~ OS2~2.0~IBM~ETHERNET ~ ~ ,,, ~ R_20_OET ~ ~ 

syyyyyyyyyyyy os220pc.cnf 310 N ~ OS2~2.0~PCNET ~-~,,, ~ R_20_OPC ~ ~ 

syyyyyyyyyyyy os220pc.cnf 310 N ~ OS2~2.0~PCNET/A ~~, ~ R_20_OPCA ~ ~ 

syyyyyyyyyyyy os220tr.cnf 310 N ~ OS2~2.0~TOKEN~RING ~ ~,,, ~ R_20_OTK ~ ~ 

syyyyyyyyyyyy 0s2203ei.cnf 310 N ~ OS2~2.0~3COM~ETHERLINK~Il ~ ~ ,,, ~ R_20_3CELNK_II ~ ~ 

syyyyyyyyyyyy 0s2203em.cnf 310 N ~ OS2~2.0~3COM~ETHERLINK~MC ~ ~ ,,, ~ R_20_3CELNK_MC ~ ~ 

syyyyyyyyyyyy os220lae.cnf 310 N ~ OS2~2.0~IBM~LAN~ADAPTER~FOR~ETHERNET ~ ~ ,,, ~ R_20_OETLAE ~ ~ 
syyyyyyyyyyyy os220ps2.cnf 310 N ~ OS2~2.0~IBM~PS/2~ADAPTER~FOR~BNC/UTP ~ETHERNET ~ —~ ,,, ~ R_20_OETPS2 ~ ~ 
syyyyyyyyyyyy 08220316.cnf 310 N ~ OS2~2.0~3COM~ETHERLINK~16~(3C507) ~ ~ ,,, ~R_20_OET316 ~ ~ 

syyyyyyyyyyyy 082203e3.cnf 310 N ~ OS2~2.0~3COM~ETHERLINK~IllI~(3C509) ~ ~ ,,, ~ R_20_OET3E3 ~ ~ 

syyyyyyyyyyyy os220wdp.cnf 310 N ~ OS2~2.0~SMC~ETHERCARD~PLUS~ELITE16 ~ ~ ,,, ~ R_20_OETWDP ~ ~ 

syyyyyyyyyyyy 08220164.cnf 310 N ~ OS2~2.0~IBM~TOKEN~RING~NETWORK~16/4~ADAPTER~Il ~ ~ ,,, ~ R_20_OTK164 ~ ~ 
syyyyyyyyyyyy os220aae.cnf 310 N ~ OS2~2.0~IBM~LAN~ADAPTER/A~FOR~ETHERNET ~ ~ ,,, ~ R_20_OETAAE ~ ~ 
syyyyyyyyyyyy os220ls.cnf 310 N ~ OS2~2.0~IBM~LANSTREAMER~MC~32~TOKEN~RING ~ —~ ,,, ~ R_20_OTKLS ~ ~ 
syyyyyyyyyyyy os22tet.cnf 310 N ~ OS2~2.1~IBM~ETHERNET ~ ~ ,,, ~ R_21_OET ~ ~ 

syyyyyyyyyyyy os221pc.cnf 310 N ~ OS2~2.1~PCNET ~-~,, ~R_21_OPC ~ ~ 

syyyyyyyyyyyy os221pc.cnf 310 N ~ OS2~2.1~PCNET/A ~~, ~ R_21_OPCA ~ ~ 

YYYYYYYYyyyy os221tr.cnf 310N~ OS2~2.1~TOKEN~RING ~ ~,,, ~ R_21_OTK ~ ~ 

syyyyyyyyyyyy 082213ei.cnf 310 N ~ OS2~2.1~3COM~ETHERLINK~ll ~ ~ ,,, ~ R_21_3CELNK_Il ~ ~ 

syyyyyyyyyyyy 082213em.cnf 310 N ~ OS2~2.1~3COM~ETHERLINK~MC ~ ~ ,,, ~ R_21_3CELNK_MC ~ ~ 

syyyyyyyyyyyy os221lae.cnf 310 N ~ OS2~2.1~IBM~LAN~ADAPTER~FOR~ETHERNET ~ ~ ,,, ~ R_21_OETLAE ~ ~ 
syyyyyyyyyyyy 0s221ps2.cnf 310N ~ OS2~2.1~IBM~PS/2~ADAPTER~FOR~BNC/UTP ~ETHERNET ~ —~ ,,, ~ R_21_OETPS2 ~ ~ 
syyyyyyyyyyyy 08221316.cnf 310 N ~ OS2~2.1~3COM~ETHERLINK~16~(3C507) ~ ~ ,,, ~ R_21_OET316 ~ ~ 

syyyyyyyyyyyy 082213e3.cnf 310 N ~ OS2~2.1~3COM~ETHERLINK~Ill~(3C509) ~ ~ ,,, ~ R_21_OET3E3 ~ ~ 

syyyyyyyyyyyy os221wdp.cnf 310 N ~ OS2~2.1~SMC~ETHERCARD~PLUS~ELITE16 ~ ~ ,,, ~ R_21_OETWDP ~ ~ 

syyyyyyyyyyyy 08221164.cnf 310 N ~ OS2~2.1~IBM~TOKEN~RING~NETWORK~16/4~ADAPTER~Il ~ ~ ,,, ~ R_21_OTK164 ~ ~ 
syyyyyyyyyyyy os221taae.cnf 310 N ~ OS2~2.1~IBM~LAN~ADAPTER/A~FOR~ETHERNET ~ ~ ,,, ~ R_21_OETAAE ~ ~ 
syyyyyyyyyyyy os221ls.cnf 310 N ~ OS2~2.1~IBM~LANSTREAMER~MC~32~TOKEN~RING ~ —~ ,,, ~ R_21_OTKLS ~ ~ 
syyyyyyyyyyyy 0s230et.cnf 310 N ~ OS2~V3~IBM~ETHERNET ~ ~,,, ~ R_230_OET ~ ~ 

syyyyyyyyyyyy 0s230pc.cnf 310 N ~ OS2~V3~PCNET ~~ ,,, ~ R_230_OPC ~ ~ 

syyyyyyyyyyyy 0s230pc.cnf 310 N ~ OS2~V3~PCNET/A ~ ~,,, ~ R_230_OPCA ~ ~ 

syyyyyyyyyyyy 0s230tr.cnf 310 N ~ OS2~V3~TOKEN~RING ~ ~ ,,, ~ R_230_OTK ~ ~ 

syYYYYYyyyyyy 082303ei.cnf 310 N ~ OS2~V3~3COM~ETHERLINK~Il ~ ~ ,,, ~ R_230_3CELNK_II ~ ~ 

syyyyyyyyyyyy 082303em.cnf 310 N ~ OS2~V3~3COM~ETHERLINK~MC ~ —~ ,,, ~ R_230_3CELNK_MC ~ ~ 

syyyyyyyyyyyy os230lae.cnf 310 N ~ OS2~V3~IBM~LAN~ADAPTER~FOR~ETHERNET ~ — ,,, ~ R_230_OETLAE ~ ~ 
syyyyyyyyyyyy 0s230ps2.cnf 310 N ~ OS2~V3~IBM~PS/2~ADAPTER~FOR~BNC/UTP ~ETHERNET ~ —~ ,,, ~ R_230_OETPS2 ~ ~ 
syyyyyyyyyyyy 08230316.cnf 310 N ~ OS2~V3~3COM~ETHERLINK~16~(3C507) ~ ~ ,,, ~ R_230_OET316 ~ ~ 

syyyyyyyyyyyy 082303e3.cnf 310 N ~ OS2~V3~3COM~ETHERLINK—~Ill~(3C509) ~ ~ ,,, ~ R_230_OET3E3 ~ ~ 

syyyyyyyyyyyy os230wdp.cnf 310 N ~ OS2~V3~SMC~ETHERCARD~PLUS~ELITE16 ~ ~ ,,, ~ R_230_OETWDP ~ ~ 

syyyyyyyyyyyy 08230164.cnf 310 N ~ OS2~V3~IBM~TOKEN~RING ~NETWORK~16/4~ADAPTER~Il ~ ~ ,,, ~ R_230_OTK164 ~ ~ 
syyyyyyyyyyyy os230aae.cnf 310 N ~ OS2~V3~IBM~LAN~ADAPTER/A~FOR~ETHERNET ~ ~ ,,, ~ R_230_OETAAE ~ ~ 
syyyyyyyyyyyy 0s230ls.cnf 310 N ~ OS2~V3~IBM~LANSTREAMER~MC ~32~TOKEN~RING ~ ~ ,,, ~ R_230_OTKLS ~ ~ 
syyyyyyyyyyyy pcinit.cnf 310 NPCNET INTERNAL~USE~ONLY ~ ~ ,,, ~ R_PCINIT ~ ~ 





Figure 169. RPL.MAP (Part 1 of 2). Modified by GETRPL for DOS and OS/2 2.1 with IBM Token-Ring Adapter 
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; workstation record fields: 
1 = adapter id (12 hex digits) 
workstation name 


t 


2 

3 

4 image file for dos (.img), fit file for os2 (fit) 
5 = name of rpl server 
6 

7 

A 


= boot drive for OS2, domain name for DOS 
8,9 = parameters for device drivers 1,2,3 
additional memory for device drivers 1,2,3. Default: ,,, 


; B = ~ for os2, Z for dos 

; Cc = workstation type; first letter is R -> enabled, D -> disabled 
Di. =~ 

PE = volumeid string for dos, IML image file for os2 

ae = P for OS/2 PCNet clients only 


; workstation records 
100FFFFFFFFF DEFAULT ~ imagefile ANYSRV0O1 ANYDOMO1 ~ ~ ~ ,,,ZR_DTK ~ ~ 
1000FFFFFFFF DEFALT20 ~ FITS\DEFALT20 ANYSRVO1 Z ~ ~ ~ ,,, ~ R_21_OTK ~ ~ 








Figure 170. RPL.MAP (Part 2 of 2). Modified by GETRPL for DOS and OS/2 2.1 with IBM Token-Ring Adapter 


Note: The only task of the two workstation entries made by the GETRPL utility is 
to enable remote IPL services. You may delete them if you have defined 
at least one remote IPL client (DOS or OS/2). If you don't have at least 
one workstation record, you should disable the REMOTEBOOT service in 
your IBMLAN.INI so that the server can be started. 


Table 17 (Page 1 of 2). Description of the Workstation Record Fields 


Field Name / Value Description 








ft 1OOFFFFFFFFF This field specifies the unique burned-in 12-character LAN 
adapter address of the primary LAN adapter in the Remote IPL 
workstation to which this entry refers. This field can also 
contain question mark (?) characters for DOS Remote IPL 
records, which are used as wildcards, for example, 
10005AABB???. Do not use these wildcard characters in OS/2 
remote IPL records. 











2 DEFALT20 This field is the workstation machine name which can be up to 
15 characters long. 
3 ~ This field is not used. It must contain a tilde (~) character. 
FITS DEFALT20 For DOS Remote IPL, this field specifies the file name of the 


diskette image file to be used to IPL the DOS workstation. An 
extension of .IMG is assumed. This field is limited to 8 
characters for a DOS workstation. For OS/2 Remote IPL, this 
field specifies the name of the FIT file to be used to start the 
workstation. This name usually is relative to the RPLDIR path. 
An extension of .FIT is assumed. 


5 ANYSRVO1 For DOS Remote IPL, this field is the name of the Remote IPL 
server where the diskette image file and other files for the 
DOS workstation are stored. This name is limited to 15 
characters (15 bytes). 


6 Z or ANYDOMO1 For DOS remote IPL, this field contains the name of the 
domain. For OS/2 remote IPL, this field contains the ID of the 
remote IPL boot drive. Use a letter from C through Z. Do not 
specify a local hard-disk drive letter. 
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Table 17 (Page 2 of 2). Description of the Workstation Record Fields 
Field Name / Value Description 


7,8,9 ~ For OS/2 and DOS Remote IPL, these fields specify 
parameters for the IBM LAN Support Program device drivers 
1, 2, and 3. They contain one tilde (~) character each, 
separated by spaces, indicating that no parameters are being 
passed. 


* Device driver 1 corresponds to the DXMAOMOD:SYS file. 


* Device driver 2 corresponds to the DXMCOMOD.SYS or 
DXMGOMOD.SYS file. 


* Device driver 3 corresponds to the DXMTOMOD.SYS file. 


You can replace ~ characters according to the device driver's 
parameter you want to pass along. For example, to pass a 
locally administered address to driver 2, fields 7, 8, and 9 
would be: ~ 400063870001 ~ 


10 i For DOS Remote IPL, this field specifies additional memory for 
device drivers 1, 2, and 3. The default is three commas (.,,). 
Modify the driver 3 portion of this field (,,driver_3,) when the 
NetBIOS parameters must be increased over the default 
values. But be aware of additional memory required at the 
Remote IPL client. Determine the value for this field 
experimentally. 


11 Z or ~ For DOS Remote IPL, this field specifies the LASTDRIVE value. 
The default is Z. For OS/2 Remote IPL, this field must contain 
a tilde (~) character. 


12 R..... or Du... This field designates the server record to use for this 
workstation. This field must match field 12 of one of the 
server records in the RPL.MAP file on the same Remote IPL 
server. D..... stands for a disabled record, R..... means 


enabled. 
13 ~ This field is reserved and must contain a tilde (~) character. 
14 ~ This field is not used. It must contain a tilde (~) character. 
15 P or ~ If this field is set to P, the workstation has a PC Network 


adapter and field 12 contains an OS/2 server record identifier. 
Otherwise, this field must contain a tilde (~) character. This 
field is not used by DOS remote IPL. 











The RPL.MAP file resides in the IBMLAN RPL directory. Lines beginning with a 
semicolon are not interpreted. Depending on the DOS and OS/2 versions, as 
well as the LAN adapters you are going to use for Remote IPL, you will have to 
make modifications to the RPL.MAP file. The GETRPL command, which is 
described in “GETRPL Remote IPL Post-Install Utility’ on page 303, updates the 
RPL.MAP file to enable server records that correspond to a LAN adapter type 
found in the server at the time the utility was being run. 


If you need more LAN adapters to be supported, refer to “Enabling Server 
Records” on page 332. 


Understanding OS/2 Server Record Identifier 

Since the graphical user interface of LAN Server Administration does not include 
selectable configuration support for defining Remote IPL clients, an 

understanding of how OS/2 LAN Server 4.0 creates the Remote IPL client specific 
configuration files is needed. 


In comparison to former LAN Server versions, the Remote IPL client's 
CONFIG.SYS file, for example, is now built dynamically. It consists of: 
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A non-transport part, which resides in the IBMLAN RPL MACHINES 
subdirectory, for example: 











C: IBMLAN RPL MACHINES DEFALT21 CONFIG. DEF 


























A transport part, which is read out from the boot block definition file, that 
points to, for example: 























C: IBMLAN RPL IBMCOM TOKENRNG CONFIG.NET 











assuming the token-ring adapter was mentioned in the boot block definition 
file. 


Note: The PROTOCOL.INI file also resides in the above mentioned directory. 
Apart from pointing to the LAN adapter support to be used at the remote IPL 
client, OS/2 server record IDs also represent the OS/2 version to be started at 
the remote IPL client. Certain rules have to be considered to work together with 
the LAN Server Administration GUI. 

Speaking of the server record identifier, these simple rules have to be followed: 


1. The first character must be the letter R (which means enabled) followed by 
an underscore (such as R_). 


2. The third character must be the number 2 (which means OS/2, such as R_2). 


3. The fourth and fifth character represent the OS/2 version followed by an 


underscore: 
0 is used for OS/2 2.0 Example:R_20_ 
1 is used for OS/2 2.1 Example:R_21_ 
30 is used for OS/2 3.0 Example:R_230_ 


4. All following characters (length must not exceed 40 characters) are 
descriptive comments. Usually the name of the LAN adapter is mentioned 
here. For example: R_230_OTK, which stands for loading OS/2 Warp Version 3 
with IBM Token-Ring LAN adapter support. 


Accordingly, for each Remote IPL client to be defined, whether via GUI or 
command line, the template FIT tables and configuration files that are used for 
creation of Remote IPL client-specific configuration files are: 


Server Record Identifier: R_20_xxxx points to 
an OS/2 V2.0 operating system. 
That means these files are being used as patterns for RIPL OS/2 2.0 clients: 


\ IBMLAN\RPL\FITS 
- 2-5 -------------------- DEFALT20.FIT 
\ IBMLAN\RPL\MACHINES \ DEFALT20 
----------- CONFIG. DEF 
\ IBMLAN\RPL\MACHINES \ DEFALT20\ IBMLAN 
---- IBMLAN. INI 





























Figure 171 (Part 1 of 2). Overview: Dynamic Building of Remote IPL Configuration Files 
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According to the boot block definition file which mentioned in field 2 of 
the server record entries, the PROTOCOL.INI will be created and stored in: 





\ IBMLAN\RPL\MACHINES \ DEFALT20 
SSRs SsSse PROTOCOL. INI 











Server Record Idendifier: R_21_xxxx points to an OS/2 
V2.1 operating system. 
That means these files are being used as patterns for RIPL OS/2 2.1 clients: 


\ IBMLAN\RPL\FITS 
------------------------ DEFALT21.FIT 





























\ IBMLAN\RPL\MACHINES \ DEFALT21 
ies wake CONFIG. DEF 
\ IBMLAN\RPL\MACHINES \ DEFALT21\IBMLAN 
---- IBMLAN. INI 


According to the boot block definition file which mentioned in field 2 of 
the server record entries, the PROTOCOL.INI will be created and stored in: 








\ IBMLAN\RPL\MACHINES \ DEFALT21 
Pola Sa PROTOCOL. INI 











Server Record Idendifier: R_230_xxxx points to an OS/2 Warp, Version 3 operati 
That means these files are being used as patterns for RIPL OS/2 Warp, Version 3 


\IBMLAN\RPL\FITS 
------------------------ DEFALT30.FIT 


























\ IBMLAN\RPL\MACHINES \ DEFALT3 0 
a a area CONFIG. DEF 
\ IBMLAN\RPL\MACHINES \ DEFALT3 0 \ IBMLAN 
---- IBMLAN. INI 


According to the boot block definition file which mentioned in field 2 of 
the server record entries, the PROTOCOL.INI will be created and stored in: 








\ IBMLAN\RPL\MACHINES \ DEFALT3 0 
Se ee PROTOCOL. INI 











Ing system 
clients: 











Figure 171 (Part 2 of 2). Overview: Dynamic Building of Remote IPL Configuration Files 


Therefore, if you need to update configuration files such as, CONFIG.SYS or FIT, 
you need to edit these files so that each Remote IPL client gets the same 
updates while the Remote IPL client is being created. 


Note: If you do not follow the naming convention described here, the server 
record identifiers will not be selectable from the graphical user interface. 
They may be used from the command line though. 


Boot Block Definition (.CNF) File 

Boot block definition files define an operating system and the way it is loaded 
into a remote IPL workstation. Every server record in the RPL.MAP file must 
contain a reference to a boot block definition. 


Typically, you do not need to change boot block definition files unless it is 
necessary to have the Remote IPL requester operate with different network 
drivers. A default .CNF file is provided for all supported network adapters. A list 
of supported LAN adapters is found in Figure 197 on page 333. 


Using the boot block definition file, the Remote IPL service creates a boot block 
which is sent to the requester. This transmission occurs at the beginning of the 
IPL process. 
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The following examples show the default OS/2 .CNF and DOS .CNF files for IBM 
Token-Ring that are provided with the Remote IPL service of OS/2 LAN Server 
4.0 


; DOS Boot Block Configuration (IBM Token Ring) 

BASE 7C0OH 

RPL DOS\RPLBOOT. SYS 

LDR DOS\RPLLOADR.COM ~ 

DAT C:\IBMLAN\DOSLAN\LSP\DXM.MSG 

DRV C: \IBMLAN\DOSLAN\LSP\DXMTOMOD.SYS PBA=0~S=12~ST=12~C=14~0O=Y ~ 
DRV C:\IBMLAN\DOSLAN\LSP\DXMCOMOD.SYS ~~ M 

DRV C: \IBMLAN\DOSLAN\LSP\DXMAOMOD.SYS 001 ~ M 








Figure 172. DOS Boot Block Definition File DOSBBTR.CNF 


; OS/2 Boot Block Configuration (IBM Token Ring) 


PL. DOS\RPLBOOT. SYS 

T DOS\MFSD20.SYS 

RG 1000H 

DR OS2.21\0S2LDR ~ OS2LDR UFSD.SYS MFSD20.SYS 
DOS\UFSD.SYS 

C: \IBMLAN\DOSLAN\LSP\DXM.MSG 

RV C: \IBMLAN\DOSLAN\LSP\DXMTOMOD.SYS PBA=0~O=Y ~ ~ 
RV C: \IBMLAN\DOSLAN\LSP\DXMCOMOD.SYS ~ ~ 

RV C: \IBMLAN\DOSLAN\LSP\DXMAOMOD.SYS 001 ~ 


> 


m 
m 





ONO Ol EPO. Ane 
> Pp 




















Figure 173. OS/2 Boot Block Definition File OS221TR.CNF 


Speaking of path and directory names, all file name fields either can be 
expressed relative to RPLDIR, which is specified in the [Remoteboot] section in the 
IBMLAN.INI file: 


RPLDIR = C: BMLAN RPL 
































or can be fully qualified. If they are qualified, the entire path must be specified, 
including the drive letter and all the subdirectories. 


All fields, including .CNF file parameters, are separated by spaces. Some .CNF 
parameters can contain parameter lists to be used by other software though. 
Fields of these embedded parameter lists must be separated by tilde (~) 
characters. 


The following table describes .CNF file entry types, along with their expected file 
names and parameters: 





Table 18 (Page 1 of 2). Description of the .CNF (Boot Block Definition File) Entries 
Entry Description 


RPL Only one RPL entry can be in a .CNF file. The file name field of this entry specifies the 
name of the first program to be run on the IPL workstation. No parameters come along 
with this file entry. 


ORG Only one ORG entry can be in a .CNF file. The second file name field of this entry 
specifies the hexadecimal segment number of a contiguous memory block on the IPL 
workstation. Files following this entry in the .CNF file are bound to this memory 
address. No parameters come along with this file entry. 


DAT Several DAT entries can be ina .CNF file. Their file name fields specify data files to 
be stored in the boot block. These files are not used by RPLBOOT.SYS, but they can 





be read by DOS handle I/O functions. No parameters come along with this file entry. 
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Table 18 (Page 2 of 2). Description of the .CNF (Boot Block Definition File) Entries 
Entry Description 


LDR Only one LDR entry can be in a .CNF file. The file name field of this entry specifies the 
name of the loader to use on the IPL workstation. For OS/2 Warp Version 3, this entry 
must include the following file name and parameters: 


O0S2.30\O0S2LDR ~ OS2LDR OS2KRNL RPLMFSD.SYS 


EXE One or more EXE entries can be in a .CNF file. Their file name fields specify names of 
executable files that are to be used on the IPL workstation. The parameter fields of an 
EXE entry are passed on to the executable when it runs. 


DRV One or more DRV entries can be in a .CNF file. Their file name fields specify names of 
device drivers to be used on the IPL workstation. Each driver entry requires the 
following parameter fields: 


1. The parameter list for the device driver. Fields of this embedded parameter list 
must be separated by tilde (~) characters in the .CNF file. 


2. The additional memory requirements of the device driver, if any, are expressed in 
decimal kilobytes. 


3. Use the character M if the driver can be moved after initialization. Otherwise, this 
parameter must be a tilde (~) character. 


If the driver can be moved and it requires less memory than the original driver 
image, RPLBOOT.SYS moves the driver to reclaim the unused memory and adjusts 
all interrupt vectors that point into the driver's memory area. 


Notes: 


The order of field entries must be considered. Place EXE entries before DRV 
entries. This change allows movable drivers to be placed in memory freed by 
completed .EXE files. 


DRV statements are order dependent. They are processed in reverse order, from 
last to first. 


BASE Only one BASE entry can be in a .CNF file. The second field of this entry specifies the 
hexadecimal segment number (paragraph) that is the boot block base address. Default 
base address is X'00COH'. 





DOS IPL Images 
Images specify which files are used to remote IPL DOS requesters. An IPL 
image is a file containing a binary representation of a bootable DOS diskette. 


DOS IPL images are binary files structured to look like files used during a 
normal IPL. You can manage DOS IPL images using the LAN Server 
Administration GUI or command line commands. DOS requesters can also be 
started from an image on a diskette. Such workstations are called 
diskette-based workstations. 


Diskette-based workstations can use the diskette to do an initial program load of 
DOS LAN Services if the image was created with DOS LAN Services. 


See “Create DOS IPL Images” on page 307 for more details. 


File Index Table (FIT) 

Required for OS/2 remote IPL, a file index table (FIT) maps OS/2 workstation file 
names to server file names. Another valid expression of a FIT is a mapping file. 
Since FIT files are ASCII files, you can update them using an ASCII editor. 


Three .FIT files are provided with OS/2 LAN Server 4.0 


¢ DEFALT20.FIT for remote IPL OS/2 2.0 clients 
* DEFALT21.FlIT for remote IPL OS/2 2.1 / 2.11 clients 
* DEFALTSO.FIT for remote IPL OS/2 Warp Version 3 clients 
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The file index table (FIT) is used for OS/2 Remote IPLFIT file. Defined in the 
workstation section of the RPL.MAP file, it is sent to a requester as part of the 
boot block record. 


A file index table consists of a header record specifying the name of the default 
network share where files can be found, followed by file-name mapping records. 
The mapping records are files that specify A-is-equal-to-B (A=B) pairs. The 
mapping records consist of a prototype file name or prefix, that means, file 
names or prefixes that are to be mapped, followed by a space, and an actual file 
name or prefix, relative to the network share. A semicolon character (;) is used 
anywhere on a line of the FIT to begin a comment. Blank lines are ignored. 


If the prototype matches a proper prefix (part of the path name, ending in ) of 
the name to be matched, the matched portion is replaced by the actual prefix. 


If there is an exact match, it is used for substitution. If several prototypes match, 
the longest match is selected for substitution. 


Network netnames can also be included as part of the substitution text, in which 
case the netname on the first line is ignored. The ability to specify the network 
netname also provides the capability to use files and applications located on a 
server other than the default server. 


Using Wildcard Characters in the RPL.MAP File: The wildcard characters (?) 
and (*) are supported subject to the following rules: 


* Wildcard characters can appear only in the prototype file name field. They 
cannot appear in the target server name field. 


Wildcard references can be redirected only to the directory level. For 
example, the following is valid: 








Z: OS2\*.IN ANYSRV01 WRKFILES DEFALT20 O0S2 


























The following is not valid: 











Z: OS2 *.IN ANYSRV01 WRKFILES DEFALT20 OS2 ANY.IN 



































The ? and * cannot both appear in the same prototype file name field. For 
example, the following is not valid: 





Z: OS2 ANY???.* ANYSRV01 WRKFILES DEFALT20 OS2 

















A brief example of a FIT file follows. The lines are numbered here for reference 
in the following discussion; the line numbers do not appear in the actual FIT file. 


1 





ANYSRV01 RPLFILES 
































Z:\CONFIG.SYS MACHINES \DEFALT21\CONFIG.SYS 
Z:\OS2 OS2 

go to a different share 
:\OS2\SYSTEM\SWAPPER.DAT \\ANYSRV01\WKRFILES\DEFALT21\0S2\SYSTEM\SWA 
Z:\ \\ANYSRV01\WRKFILES\DEFALT21 











N 





























YHOU PWD 




















In this example, ANYSRVO1 is the Remote IPL server name, and DEFALT21 is the 
workstation name. 





Line Description 
1 Defines the default remote IPL server and network share name. 
2 Empty line. 
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Translates all references to Z: CONFIG.SYS to: 
ANYSRV01 RPLFILES MACHINES DEFALT21 CONFIG.SYS 



































Note that the default netname is automatically prefixed to the 
translated name. 


Translates all references to Z: OS2 to: 





ANYSRV01\RPLFILES\OS2 











Except for explicitly mapped file names (see line 6), this record 
results in all Z: OS2 *.* references being translated to: 





ANYSRV0O1 RPLFILES OS2 *.* 











Subdirectory references are also mapped by this statement. For 
example, Z: OS2 DLL ANYFILE.DLL is translated to: 


ANYSRV01 RPLFILES OS2 DLL ANYFILE.DLL 
































Is a comment. 
Translates all references to Z: OS2 SYSTEM SWAPPER.DAT to: 
ANYSRV01 WKRFILES DEFALT21 0S2 SYSTEM SWAPPER. DAT 
































Note: In this example, the default netname is overridden by 
specifying the explicit UNC name. The translated file name is 
to the requester-unique file structure where the requester has 
read, write, create, delete, and execute access. Swapping 
here is defined on the remote server in comparison to local 
swapping. 


Translates all other references to be relative to: 





ANYSRV01 WRKFILES DEFALT21 














Note that the translated path is to the requester-unique file structure 
on the server for which the requester has read, write, create, delete, 
and execute authority. 


The following is an example of excerpts from the DEFALT21.FIT file, as shown in 
Figure 174. 





\\ANYSRV01\RPLFIL 





ES 


; The first line of this file MUST be UNC name 
; Per-workstation read-only configuration files. 


Z:\CONFIG.SYS 








MACHIN: 


ES\DEFALT21\CONFIG.SYS 











Figure 174 (Part 1 of 3). File Index Table DEFALT21.FIT (Original) for OS/2 2.1 Clients 


Chapter 13. Remote IPL 297 








NNNNNNNNNNNNNNNNNNNNNNNNNN* 


NNNNNNNWN* 


NNN 


NNN 


These OS/2 files must be writeable. 
















































































IBMLAN 






















































































































































































































































































































































































; All other IBMLAN files are read-only and shared. 
: \IBMLAN 








:\OS2\* . INI \\ANYSRV01\WRKFILES \ DEFALT21\0S2 

:\OS2\*.Et! \\ANYSRV01\WRKFILES \ DEFALT21\0S2 

:\OS2\* . ### \\ANYSRV01\WRKFILES \ DEFALT21\0S2 
:\OS2\INSTALL\REINSTAL.* \\ANYSRV01\WRKFILES \DEFALT21\0S2 

: \OS2\INSTALL\* . LOG \\ANYSRV01\WRKFILES \ DEFALT21\0S2 

: \OS2\SVGADATA. * \\ANYSRV01\WRKFILES \ DEFALT21\0S2 

: \OS2\SVGATMP .. BAT \\ANYSRV01\WRKFILES \DEFALT21\0S2\SVGATMP. BAT 
: \OS2\SYSTEM\SWAPPER.DAT \\ANYSRV01\WRKFILES \DEFALT21\0S2\SYSTEM\SWAPPER.DAT 
: \AUTOEXEC. BAT \\ANYSRV01\WRKFILES \ DEFALT21\AUTOEXEC. BAT 

: \SPOOL \\ANYSRV01\WRKFILES \ DEFALT21\SPOOL 

:\OS2\WP* .ICO \\ANYSRV01\WRKFILES \ DEFALT21\0S2 

:\OS2\APPS\* . INI \\ANYSRV01\WRKFILES \ DEFALT21\0S2 
:\OS2\APPS\*.!!! \\ANYSRV01\WRKFILES \ DEFALT21\0S2 

:\OS2\APPS\* . ### \\ANYSRV01\WRKFILES\DEFALT21\0S2 

:\OS2\APPS\* .TMP \\ANYSRV01\WRKFILES \ DEFALT21\0S2 

:\OS2\APPS\* .GRF \\ANYSRV01\WRKFILES \ DEFALT21\0S2 

:\OS2\APPS\* .DAT \\ANYSRV01\WRKFILES \ DEFALT21\0S2 
:\OS2\APPS\*.$?? \\ANYSRV01\WRKFILES \ DEFALT21\0S2 
:topl.OS2\MDOS\WINOS2\*.INI \\ANYSRV01\WRKFILES \DEFALT21\0S2\MDOS\WINOS2 
: \OS2\MDOS\WINOS2\*.GRP \\ANYSRV0O1\WRKFILES \DEFALT21\0S2\MDOS\WINOS2 
: \OS2\MDOS\WINOS2\*.TMP \\ANYSRV01\WRKFILES \DEFALT21\0S2\MDOS\WINOS2 
: \OS2\MDOS\WINOS2\*.CAL \\ANYSRV01\WRKFILES \DEFALT21\0S2\MDOS\WINOS2 
: \OS2\MDOS\WINOS2\*.CRD \\ANYSRV0O1\WRKFILES \DEFALT21\0S2\MDOS\WINOS2 
: \OS2\MDOS\WINOS2\*.WRI \\ANYSRV0O1\WRKFILES \DEFALT21\0S2\MDOS\WINOS2 
: \WINDOWS\SYSTEM\TEMP.* \\ANYSRV01\WRKFILES \DEFALT21\WINDOWS\TEMP 

: \WINDOWS \ TEMP \\ANYSRV01\WRKFILES \ DEFALT2 1 \WINDOWS \ TEMP 

All OS2 files are read-only and shared (except swapper.dat, os2.ini, & os2sys.ini). 
:\OS2 OS2.21\0S2 

: \WINDOWS OS2.21\WINDOWS 

: \OS2\DLL\ IBMNULL.DRV OS2.21\0S2\DLL\IBMNULL\ IBMNULL.DRV 

: \XGASDMQS OS2.21\XGASDMQS 

: \PSFONTS OS2.21\PSFONTS 

: \OS2KRNL OS2.21\0S2KRNL 

: \OS2LDR.MSG OS2.21\0S2LDR.MSG 

: \OSO001.MSG OS2.21\0S2\SYSTEM\OSO001.MSG 

Font support 

: \OS2\DLL\HELV. FON OS2.21\0S2\DLL\HELV.BGA 

: \OS2\DLL\COURIER. FON OS2.21\0S2\DLL\COURIER.BGA 

:\OS2\DLL\TIMES . FON OS2.21\0S2\DLL\TIMES .BGA 

XGA-2 ISO font support 

:\OS2\DLL\HELVI . FON OS2.21\0S2\DLL\HELVI .XGA 
:\OS2\DLL\COURIERI.FON OS2.21\0S2\DLL\COURIERI.XGA 

: \OS2\DLL\TIMESI .FON OS2.21\0S2\DLL\TIMESI .XGA 

DMA support 

: \OS2\MDOS\VDMA. SYS OS2.21\0S2\MDOS\VDMAPS2.SYS 

IBMLAN references 

A per-workstation read-only configuration file. 

: \IBMLAN\ IBMLAN . INT MACHINES \ DEFALT21\IBMLAN\IBMLAN. INI 
Per-workstation writeable IBMLAN files. 

: \IBMLAN\LOGS \\ANYSRV01\WRKFILES \ DEFALT21 \ I BMLAN\LOGS 

: \IBMLAN\ ACCOUNTS \\ANYSRV01\WRKFILES \ DEFALT21\ IBMLAN\ACCOUNTS 

: \IBMLAN\NWDDE \\ANYSRV01\WRKFILES \ DEFALT21 \ IBMLAN\NWDDE 

: \IBMLAN\NETPROG\*.INI \\ANYSRV01\WRKFILES \DEFALT21\ IBMLAN\N. 

: \IBMLAN\NETPROG\*.!!! \\ANYSRV01\WRKFILES \DEFALT21\ IBMLAN\NETPROG 

: \IBMLAN\NETPROG\UIFWTRC.CFG \\ANYSRV01\WRKFILES\DEFALT21\IBMLAN\NETPROG\ULIFWTRC.CFG 





Figure 174 (Part 2 of 3). File Index Table DEFALT21.FIT (Original) for OS/2 2.1 Clients 
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User Profile Management/MUGLIB files. 
Z:\MUGLIB MUGLIB 


LAN Transport drivers 


: \IBMCOM IBMCOM 
: \MPTN MPTN 
: \PRO.MSG IBMCOM\ PRO .MSG 











: \IBMCOM\PROTOCOL.INI MACHINES\DEFALT21\ PROTOCOL. INI 
: \IBMCOM\LANTRAN . LOG \\ANYSRV01\WRKFILES \DEFALT21\ IBMCOM\LANTRAN . LOG 





NNNNWN* 











Communications Manager/CMLIB files. 



































: \CMLIB CMLIB 

: \CMLIB\* .CFG \\ANYSRV01\WRKFILES \DEFALT21\CMLIB 
:\CMLIB\* .DAT \\ANYSRV01\WRKFILES\DEFALT21\CMLIB 

: \CMLIB\LOGS$ \\ANYSRV01\WRKFILES\DEFALT21\CMLIB\LOGS$ 

: \CMLIB\ACS. PRO \\ANYSRV01\WRKFILES\DEFALT21\CMLIB\ACS. PRO 

















: \CMLIB\APPN\* .NDF \\ANYSRV01\WRKFILES \ DEFALT21\CMLIB\APPN 

: \CMLIB\APPN\* .CF2 \\ANYSRV01\WRKFILES \ DEFALT21\CMLIB\APPN 

: \CMLIB\APPN\* .SEC \\ANYSRV01\WRKFILES \ DEFALT21\CMLIB\APPN 

: \CMLIB\APPN\* . LOG \\ANYSRV01\WRKFILES \ DEFALT21\CMLIB\APPN 

: \CMLIB\APPN\* .22Z \\ANYSRV01\WRKFILES \ DEFALT21\CMLIB\APPN 
:\OS2\EPW. INI \\ANYSRV01\WRKFILES \DEFALT21\0S2\EPW. INI 

: \IBMCOM\ PROTOCOL.~MP \\ANYSRV01\WRKFILES \DEFALT21\ IBMCOM\ PROTOCOL .~MP 
The following must be customized per CFG file, replace 'cfgname' with 
the name of the CFG file that you wish to use. 

:\IBMCOM\cfgname.INI \\ANYSRV01\WRKFILES\DEFALT21\IBMCOM\cfgname. INI 

































































NNNNNNNNNNNN* 




















N 











Database Manager/SQLIB files. 

















Z:\SQLLIB SQLLIB 

Z:\SQLLIB\SQLSYSTM \\ANYSRV01\WRKFILES \DEFALT21\SQLLIB\SQLSYSTM 
Z:\SQLLIB\SQLNODIR \\ANYSRV01\WRKFILES \DEFALT21\SQLLIB\SQLNODIR 
Z:\SQLLIB\SQLDBDIR \\ANYSRV01\WRKFILES \DEFALT21\SQLLIB\SQLDBDIR 














;Map .BIO Files 
Z:\*.BIO OS2.21\0S2 


; OS/2 Remote Install 
Z:\OS2INST OS2INST 


; Touch Display support (delete next line for Touch Display support) 
Z:\OS2\DLL\TOUCALLS.DLL \\ANYSRV0O1\WRKFILES\DEFALT21\0S2\TOUCALLS.DLL 














; OS/2 version override reference 
Z:\OS2VER OS2.21\0S2VER 





; Other references go to the per-workstation root. 
Z:\ \\ANYSRV01\WRKFILES \DEFALT21 























Figure 174 (Part 3 of 3). File Index Table DEFALT21.FIT (Original) for OS/2 2.1 Clients 


The FIT files are stored in the IBMLAN RPL FITS directory depending on the 
Remote IPL client's name. Each client has its own FIT file. 


The Remote IPL service provides default RPL.MAP records, FIT files, 
CONFIG.SYS files, and DOS image definition files to use when setting up Remote 
IPL requesters. The default files are always used when defining a Remote IPL 
client. If they do not meet your requirements, you can customize your Remote 
IPL requesters by altering the default files provided. The following Figure 175 on 
page 300 illustrates the whole picture on how OS/2 RIPL locates the control files 
and downloads the system. 
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LAN Server 4.0 RIPL Service for OS/2 














RPL.MAP 
; SERVER RECORDS FOR OS2 
YYWWYYVV¥ yyy 0S220et.cnf 310 N ~ OS2~2.0~IBM~ETHERNET ~ ~ ,,, ~ R_20_OET ~ ~ 
WYWWWVVVyyyy os220tr.cnf 310 N~ OS2~2.0~TOKEN~RING ~~ ,,,~ ~ RE 20 OTK ~~ 
YYVVVVVVYV¥y 0s22aet.cnf 310N~ OS2~2.0A~IBM~ETHERNET ~ ~ ,,,~ R_20A_OET ~ ~ 
0s230trcnf 310N~ OS2~V3-~TOKEN-RING ~~,,,~ R230 OTK ~~ 


RKSTATION RECORD FIELDS: 
{QOOFFFFFFFF DEFALT20 ~ FITS\DEFALT20 RIPLSRV Z~ ~ ~ wy ~ R20A_OTK ~ ~ 
10005A228CEE RIPLWKST ~ FITS\RIPLWKST RIPLSRV Z ~ ~ ~ ,,, ~ R_230_OTK ~ ~ 


RIPLWKST.FIT (2) 


\WRIPLSRV\RPLFILES 

; The first line of this file MUST be UNC name 

; Per-workstation read-only configuration files. 

ZACOMFIG.SYS MACHINES\RIPLWKST\CONFIG.SYS 
; These 08/2 files must be writeable. 


Z50S2\*. INI \RIPLSRV\WRKFILES\RIPLWKST\OS2 

ZAOS2\* III \\WRIPLSRVWWRKFILES\RIPLWKST\OS2 

ZAOS2\" At \\RIPLSRVAWRKFILES\RIPLWKST\OS2 

ZAOS2\INSTALLIREINSTAL.* \RIPLSRV\WRKFILES\RIPLWKST\OS2 

ZAOS2\INSTALLY.LOG \RIPLSRVWREKFILES\RIPLWKST\OS2 
---- more entries here ---- 

; All OS2 files are read-only and shared (except swapper.dat, os2.ini, & os2sys.ini). 

ZA0S2 OS2.30\0S2 

Z\0S2\M DOS\WINOS2 OS2.30\0S2\MDOS\WINOS2 

ZAOS2\DLLVIBMNULL.DRY O$2.30\0S2\DLL\IBMNULL\IBMNULL.DRV 

Z\XGA$DMQS OS2.30\XGA$DMOS 








MAPPING 











---- more entries here ---- 





OS230TR.CNF Boot Block Configuration File 












































RPL DOS\RPLBOOT.SYS OS/2 System files 
DAT DOS\MFSD20.SYS 

ORG 1000H READ only 

LDR O$2.30\0S2LDR ~ OS2LDR UFSD.SYS MFSD20.SYS \IBMLANRPL\O82.20 

DAT DOS\UFSD.SYS © 

DAT G:\IBMLAN\DOSLAN\LSP\DXM.MSG DLL, CMD... 
DRV C:\IBMLAN\DOSLAN\LSP\DXMTOMOD.SYS PBA=0~O=Y ~ ~ 

DRV C:\IBMLAN\DOSLAN\LSP\DXMCOMOD.SYS ~ ~ eet Geese ReR 
DRV C:\IBMLAN\DOSLAN\LSP\DXMAOMOD.SYS 001 ~ 









| | 


(4) Client Initialization 


Boot Block Configuration File 
FIT File 





Access control 




















(1) Request remote IPL = 


LAN Address = 10005A228CEE 










































































Figure 175. OS/2 Remote IPL Mechanism 


For more information about the Remote IPL service, contents of the default files, 
and how you can customize the default files, see “Procedures for Remote IPL 
Service” on page 301 before you start using any of the procedures described in 
this chapter. 
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Procedures for Remote IPL Service 


The remote workstation must be equipped with a LAN adapter with the 
appropriate Remote IPL support installed. LAN adapters that support Remote 
IPL are listed in Figure 197 on page 333. 


When the Remote IPL service is running on the server, it monitors the LAN for 
Remote IPL requests. When a Remote IPL request is received, the service 
checks the RPL.MAP file to see if the workstation is defined as a valid Remote 
IPL workstation. If there is an entry for the workstation in the RPL.MAP file, the 
Remote IPL server uses the entry to determine the type of IPL defined for the 
workstation (DOS, reference diskette image, or OS/2 file system driver). The 
service then initiates the appropriate type of Remote IPL to the workstation. 


The DOS or reference diskette Remote IPL capability has not changed in 
comparison to previous versions of OS/2 LAN Server. An image file made from 
the appropriate system diskette is used to start the workstation. Image files are 
created using the LAN Server MAKEIMG utility or the LAN Server Administration 
GUI. Existing DOS LAN Services image files created with previous versions of 
OS/2 LAN Server can be used directly with the remote IPL service. They have to 
be copied to the IBMLAN DCDB IMAGES directory. 


Note: Be aware of changing the adapter I/O range on Ethernet adapters from 
X'0200-021F' to X'0280-029F' when you need to have a virtual disk 
(VDISK.SYS) available on Remote IPL clients. 


The behavior of OS/2 Remote IPL is similar to DOS Remote IPL at the beginning 
of a Remote IPL process. It uses some common server components. The 
process itself differs from the DOS Remote IPL by using a mini-file system driver 
(mini-FSD). The mini-FSD consists of base device drivers, dynamic link libraries, 
the CONFIG.SYS file, network device drivers, and the redirector that are loaded 
before OS/2 itself will be loaded. In comparison to DOS Remote IPL, OS/2 
Remote IPL does not need complete diskette images. It uses common files and 
workstation dependent configuration files. 


OS/2 remote requesters must have access to the OS2, MUGLIB, IBMLAN, and 
user directories. Two standard netnames for this are provided on the Remote 
IPL server: 


RPLFILES 


- The RPLFILES netname allows only read and execute access to the files 
defined under its structure. It points to the IBMLAN RPL directory on 
the Remote IPL server and contains the workstation copies of the 
specific files on the root and under the OS2 (OS2.20; OS2.21; OS2.30) 
directory. They are accessed through this netname as well as 
workstation-unique read-only and execute-only files. Each workstation 
has a unique directory structure under RPLFILES in which such 
workstation-unique files are maintained. 


+ WRKFILES 


- The WRKFILES netname is used to access all directory structures and 
files for which the workstation must have read, write, create, delete, and 
execute authority. It points to the IBMLAN RPL MACHINES directory on 
the Remote IPL server and contains for each workstation a unique 
directory structure. This directory includes files such as OS2.INI, 
OS2SYS.INI, NET.ERR, and LANTRAN.LOG. If swapping on the remote 
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server is selected, the SWAPPER.DAT file is also located in this 
directory. 


The remote workstation does not have to do anything explicitly to reference files 
through these two netnames. When a remote workstation is started, the 
mini-FSD automatically translates all file references to be relative to RPLFILES or 
WRKFILES prior to sending the request to the server. This file name translation 
is controlled by the a file index table (FIT) that is sent to the remote workstation 
when it is started. 


Setting Up a Remote IPL Environment 


RIPLINST Utility 
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To set up a Remote IPL environment, you must understand these processes: 
1. How to set up a Remote IPL server with the RIPLINST and GETRPL utility 


2. How to create DOS and OS/2 records for the RPL.MAP file using the LAN 
Server Administration GUI 


3. How to update FIT files for OS/2 Remote IPL workstations 
4. How to customize DOS Remote IPL workstations 


5. How to customize OS/2 Remote IPL workstations 


The RIPLINST utility installs the OS/2 operating system into a subdirectory on the 
OS/2 LAN Server. This copy is the central copy of the OS/2 operating system 
that the Remote IPL requesters use. All files required for Remote IPL are copied 
into this subdirectory, including OS/2 device drivers and display support 

routines. 


The RIPLINST utility is shipped with the OS/2 operating system. Independent of 
the OS/2 version the RIPLINST utility resides on the OS/2 diskette 7 in a packed 
form. To use this utility, you must first unpack it with the UNPACK command. 
For more information refer to “OS/2 Remote IPL Support” on page 377. 


To start the RIPLINST utility: 


1. Type the following command: 





--RIPLINST ~ 75-55-55 -------------------------------- 














2. When the IBM logo is displayed, select OK. 


3. The OS/2 Installation for Remote IPL window is displayed. In this window, 
you are provided the option to change the values for the following fields: 


Inside OS/2 LAN Server 4.0 





Figure 176. OS/2 2.1 Installation for Remote IPL window 


where C: is the drive where OS/2 LAN Server is installed. 


Note: It is useful to have access to the OS/2 image subdirectory of a CID 
code server. Change the source directory accordingly. Otherwise, you are 
installing OS/2 from a diskette drive. 


Important 


The OS/2 Remote IPL directory must be specified for the same drive 
where the Remote IPL service is installed. In addition, the base path of 
\IBMLAN\RPL must always be specified. 








4. Select Install when you are ready to install the OS/2 operating system for 
Remote IPL. 


5. If you are installing OS/2 from a diskette drive, you are prompted to insert a 
specific diskette from OS/2. Insert the specified diskette into the correct 
drive and select OK. Insert additional diskettes as prompted and select OK. 


6. An information window is displayed when installation has completed 
successfully. Select OK. 


7. You are returned to the OS/2 Installation for Remote IPL window. Select Exit 
to return to the OS/2 command prompt. 


You are now ready to run the GETRPL utility. Refer to “GETRPL Remote IPL 
Post-Install Utility” that follows for more information. 


GETRPL Remote IPL Post-Install Utility 


The GETRPL utility must be run on Remote IPL servers after installation or 
reinstallation of LAN Server and right after you run RIPLINST. The GETRPL 
utility provides these main functions: 


Migrates the RPL.MAP workstation and server records from previous levels 
of LAN Server into the RPL.MAP on the current Remote IPL server. 


Moves DOS Remote IPL users from previous levels of LAN Server into a 
group called RPLGROUP, and creates an access control profile for 
RPLGROUP, granting all privileges to the users in that group. 


Adds new OS/2 Remote IPL and DOS Remote IPL users to the RPLGROUP 
that are created with OS/2 LAN Server 4.0. 


Creates the default OS2.INI and OS2SYS.INI files. 
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If issued remotely by a CID process, it runs in an invisible window requiring 
no user inputs since the procedure is CID enabled. 


Creates the OS/2 operating system Remote IPL directory for which the 
GETRPL utility builds INI files and WPS defaults. 


Updates the RPL.MAP file to enable server records that correspond to a LAN 
adapter type found in the server. Note that only the string TOKEN or ETHER 
is looked up for server records enablement. 


Note: If Remote IPL clients with a different adapter type are booted from this 
server, the RPL.MAP file must be edited to enable the appropriate 
server records. For more information, see “Enabling Server Records” 
on page 332. 

Prerequisites to run the GETRPL utility: 
1. LAN Server is installed with the Remote IPL option on the server. 
2. The server must be started. 


Note: If the server does not start automatically, issue the following 
command at the OS/2 command prompt: 





NET START SERVER /SRVS:NETLOGON 

















3. You are logged on as an administrator. 
4. The RIPLINST utility has been run. 


5. The Remote IPL service must not be started. If the Remote IPL service was 
automatically started, you must stop this service by issuing the following 
command at the OS/2 command line: 


NET STOP RPL 





The GETRPL utility, which is CID enabled, has the following command syntax: 


--GETRPL a soo S£23 25 
-/L:logfile- -/0:0S2-dir 








Parameter Description 


IL:logfile Specifies the fully qualified path and file name of a log file. All 
messages and errors are logged in this file. 


/0:0S2_dir Specifies the OS/2 operating system Remote IPL directory for which 
the GETRPL utility builds INI files and WPS defaults, if they do not 
already exist. 


A Forces the default OS/2 INI files to be recreated. Normally, the files 
are not recreated if they already exist. 


/NA Suppresses the creation of access control profiles. 


The GETRPL utility normally uses information that RIPLINST saves in the OS2.INI 
file to determine which directory to process. You may issue the GETRPL 
command without specifying parameters if you want to go with default values. 

You can use the /O parameter to override the RIPLINST value when multiple 
operating systems are installed in the Remote IPL tree. You can specify the /O 
parameter in one of two ways: 


* As a fully qualified path. For example: 





/O:d: IBMLAN RPL 0S2.21 
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* As the root directory under IBMLAN RPL. For example: 
/0:082.21 


Note: All Remote IPL servers must run the GETRPL utility after installation or 
reinstallation of LAN Server, as well as after running the RIPLINST utility. 
Do not start the Remote IPL service before running this utility. 


After the GETRPL utility has been run, you may enter the following command at 
an OS/2 prompt to start the Remote IPL service: 


NET START RPL 





The following access control profiles are added to servers when the Server 
service is started, the Remote IPL service is installed, and GETRPL has been 


run: 





: \IBMLAN\ 
: \IBMLAN\ 
: \IBMLAN\ 
: \IBMLAN\ 
: \IBMLAN\ 
: \IBMLAN\ 
: \IBMLAN\ 
: \IBMLAN\ 
: \IBMLAN\ 
: \IBMLAN\ 
: \IBMLAN\ 


: \IBMLAN\ 
: \IBMLAN\ 
: \IBMLAN\ 


PL RPLGROUP: RX 





PL\IBMLAN RPLG 











: \IBMLAN\ 
: \IBMLAN\ 
: \IBMLAN\ 
: \IBMLAN\ 
: \IBMLAN\ 
: \IBMLAN\ 
: \IBMLAN\ 
: \IBMLAN\ 
: \IBMLAN\ 


AAGAAaAAAAAAADAAAAAAAAAAAAAAA 


R 
R 
R 
R 
R 
R 
R 
R 
R 
R 
R 
: \IBMLAN\R: 
R 
R 
R 
R 
R 
R 
R 
R 
R 
R 
R 
R 








PL\IBMLAN\NETLIB RP 


PL\OS2.2x RPLGROUP:RX 
PL\OS2.2x\SYSTEM RPLGROUP:RX 
PL\OS2.2x\OS2\APPS RPLGROUP: 
PL\OS2.2x\OS2\BITMAP RPLG 
PL\OS2.2x\0S2\BOOK RPLGRO 
PL\OS2.2x\0S2\DLL RPLGROU 
PL\OS2.2x\0S2\HELP RPLGROUP 
PL\OS2.2x\OS2\INSTALL RPLGRO 
PL\OS2.2x\OS2\MDOS RPLGROUP: 
PL\OS2.2x\PS\FONTS RPLGROUP: 
PL\OS2.2x\XGASDMQS RPLGROUP: 











L 
PL\IBMLAN\NETPROG RPLGROUP: 
PL\IBMLAN\SERVICES R 

















PL\IBMCOM RPLG 
PL \ IBMCOM\ DLL 
PL \ IBMCOM\MACS 





PL\MPTN RPLGRO 
PL\MUGLIB RPLG 
PL\DOS RPLGROU 








PL\FITS RPLGRO 





UP:RX 
ROUP: RX 
UP: RX 
P:RX 
:RX 
UP: RX 
RX 
RX 
RX 
ROUP: RX 
GROUP: RX 
RX 
PLGROUP: RX 
ROUP: RX 











RPLGROUP : RX 
RPLGROUP: RX 


PL\MACHINES RPLGROUP:RX 


UP: RX 
ROUP: RX 
P:RX 
UP: RX 

















Figure 177. RIPL Access Control Files 


where d: is the drive where the IBMLAN directory is located. 


Support for Several OS/2 Versions for Remote IPL 
As mentioned at the beginning of this chapter, a Remote IPL server supports up 
to three different OS/2 versions for Remote IPL. The following steps describe 
how to set up such a Remote IPL server. 


1. Issue the RIPLINST command as shown in “RIPLINST Utility’ on page 302. 
All OS/2 versions have have the RIPLINST utility available on the seventh 


diskette. 


2. After having issued the RIPLINST command, you may may have to change 
the OS/2 Remote IPL Directory entry at the Installation for Remote IPL 
window. For example, if you install OS/2 Warp Version 3, change the entry to 
C: IBMLAN RPL OS2.30 where C: is the drive where OS/2 LAN Server is 


installed. 


3. Following successful completion of RIPLINST, issue the GETRPL utility as 
described in “GETRPL Remote IPL Post-Install Utility’ on page 303. You do 
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not have to pass parameters with the GETRPL command since all necessary 
entries are stored in the OS/2 INI files. 


MKRDPM - Make Remote IPL Diskette - Utility 
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The MKRDPM utility creates Remote IPL diskettes which are used to initialize 
the network adapter and start the Remote IPL boot process. 


Only machines which do not have the RIPL chip installed on IBM Token-Ring, 
IBM PC Network or IBM Ethernet cards need a Remote IPL diskette to initiate 
Remote IPL. In all other cases, you can enable your network adapter for Remote 
IPL. Micro Channel machines only need a reference diskette (make sure you 
have the latest version of the reference diskette) to enable the Remote IPL 
feature of the adapter card. AT bus cards have a switch board on the LAN 
adapter. One of the settings enables Remote IPL support. 


The MKRDPM utility cannot be used for enabling Remote IPL support on LAN 
adapters that require NDIS protocol stack. When preparing the diskette, it 
enables the non NDIS protocol stack driver (DXMCOMOD.SYS). 


Before running the MKRDPM utility, make sure that you have a formatted DOS 
bootable diskette (which includes system files but no user data). The diskette 
must not be write-protected. During the Remote IPL boot process, the diskette 
must be available for both read and write operations. 


To run MKRDPM do the following steps: 


1. Insert a formatted DOS bootable diskette in drive A: 





2. At the Remote IPL server, type MKRDPM at an OS/2 command prompt and 
press Enter. The Make Remote IPL Diskette window is displayed. 





Target diskette drive 





Nelwork adapter tupe 


IBM Ethernet 
IBM PCO N 


etwork 
Lc 








Figure 178. Make Remote IPL Diskette window 


3. Select the type of network adapter used by the target workstations from the 
Network Adapter Type list. 


4. Select Create. 


5. Select Exit if you do not want to create another Remote IPL diskette. 
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Create DOS IPL Images 


To create a DOS image, you must define the image to the domain using a DOS 
image profile. The DOS image profile must be on the domain controller. The 
image profile consists of the image name and an image description. The image 
profile also contains information on whether it was defined by an image 
definition file or created from diskette. 


You can create an image profile in two ways: 


From an image definition file, an ASCII file containing a list of files that IPL 
the requester 


Directly from a diskette normally used to IPL the requester 


You can edit the image definition file to change the information it contains. The 
image is created by assembling the files in the image definition file. 


Standard image definition files are shipped with OS/2 LAN Server 4.0 You can 
use these as models to create images. 


Once an image is created, you can assign it to one or more of the currently 
defined Remote IPL DOS requesters. 


Notes: 


Some memory overhead is associated with DOS Remote IPL requesters. For 
this reason, a Remote IPL workstation and a diskette-based workstation 
loaded from the same image show different amounts of available memory. 
The Remote IPL requester has a smaller amount of memory available. 


Before creating and using IPL images, make sure that DOS Remote IPL 
Support as well as IBM IEEE 802.2 protocol is installed on the Remote IPL 
server. 


Do not delete the guest account and GUEST user ID from the Remote IPL 
server. The guest account and GUEST user ID must exist to allow the 
remote requester to gain access to the IBMLAN DCDB IMAGES, 

IBMLAN DOSLAN, and other directories on the server. 


To maintain security on a Remote IPL workstation, make sure that the 
GUEST user ID is limited to the default access, read (R), on the 
IBMLAN DCDB IMAGES, IBMLAN DOSLAN, and other directories. 


The following lists describe the file in the sample Image Definition File. If DOS 
Remote IPL was selected during installation, these files exist only if DOS LAN 
Services is installed. These files are installed on each server configured to 
support the Remote IPL service and are used with the standard image 
definitions. 
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Table 19. Image Definition File for DOS 
File Description 


STD_AUT.BAT This file includes commands in the AUTOEXEC.BAT file for a Remote 
IPL workstation initializing DOS LAN Services. The file is renamed to 
AUTOEXEC.BAT when it is included in the diskette image. The file 
resides in the IBMLAN DOSLAN NET directory. 


STD_CFG.SYS This file includes example configuration commands for the DOS 3.3 
environment of the Remote IPL workstation. This file is renamed to 
CONFIG.SYS when included in the diskette image. This file resides in 
the IBMLAN DOSLAN NET directory. 


HMA_CFG.SYS This file includes example configuration commands for the DOS 5.0 
environment of the Remote IPL workstation. HIMEM.SYS is loaded and 
DOS is put into High Memory Area. This file is renamed to 
CONFIG.SYS when included in the diskette image. This file resides in 
the IBMLAN DOSLAN NET directory. 


UMB_CFG.SYS This file includes example configuration commands for the DOS 5.0 
environment of the Remote IPL workstation. HIMEM.SYS and 
EMM386.EXE is loaded and DOS is put into High Memory Area. 
LOADHIGH (LH) commands as well as DEVICEHIGH statments are 
supported. This file is renamed to CONFIG.SYS when included in the 
diskette image. This file resides in the IBMLAN DOSLAN NET 
directory. 





To use the IBM LAN Support Program on the Remote IPL workstation, do not 
specify the device driver entries in the CONFIG.SYS file. The Remote IPL service 
sends device drivers to the workstation before running the CONFIG.SYS file. 


The following example (Figure 179) shows the contents of the UMB_CFG.SYS file 
modified for national language support. 



































COUNTRY=001, 437,A:\COUNTRY.SYS 
DOS HIGH, UMB 

SHELL=A: \COMMAND.COM /E:2000 /P 
LASTDRIVE=~~~~~ B 

FILES=30 

BUFFERS=10 

FCBS=16,8 

DEVICE=A: \HIMEM.SYS 

DEVICE=A: \EMM386.EXE noems 
DEVICE=A: \DLSHELP.SYS 





























Figure 179. UMB_CFG.SYS (Modified for NLS) Used for the Image Definition File 





Note: LASTDRIVE indicates drives reserved for DOS LAN Services use. The 
LASTDRIVE value must always be at least F in order to start DOS LAN 
Services and should be greater than the last disk partition or virtual drive 
created. Increase the drive letter by one increment for hard-disk-based 
DOS requesters and two increments for Remote IPL or diskette-based 
requesters. The default LASTDRIVE value is Z. 
































The following example (Figure 180 on page 309) shows the contents of the 
STD_AUT.BAT file modified for national language and mouse support. 
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@echo off 
prompt [$p] 


cls 


@echo =~ rn rr rrr rrr rrr rrr nr nnn ntsc nnn 


@echo 
@echo 
@echo 
@echo 
@echo 





Starting the NETWORK 


Gechoy SaeScheSce Soe sso eS SSS aS Se See eS 


NET START 
cls 





ECHO? gee SS ge ye pe 


@echo 
@echo 
@echo 
@echo 
@echo 


Q 
fe) 
53 
5 
0 
Q 
ct 
a 
3 
Q 
ct 
° 
ct 
i 
0 
Es 
H 
v 
ra 
wn 
0 
R 
< 
8 
R 


@echo Herron rr errr rr rrr nnn nnn ssnnnn 


LH %path%: \DOSLAN\DOS\KEYB US 437 %path%: \DOSLAN\DOS\KEYBOARD. SYS 
LH %path%: \DOSLAN\DOS\DOSKEY 
LH %path%: \DOSLAN\DOS\MOUSE 


Spath%: \DOSLAN\N 








ET\RIPL.BAT ~~~~~ B 


Figure 180. STD_AUT.BAT Used for the Image Definition File. This file is modified for NLS support. 


Note: The LOADHIGH (LH) option is used to take advantage of DOS upper 
memory blocks. When UMB is not found, the files are loaded into 
conventional memory. 


The following example (Figure 181) shows the contents of the RIPL.BAT file 
modified for issuing the NETGUI command after LOGON (instead of a DOS command 


prompt). 

















S1: 





CD DOSLAN\NET 


set path=%1: \DOSLAN\NET;%1:\DOSLAN\DOS; 
set comspec=%1: \DOSLAN\DOS\COMMAND .COM 

















@NET LOGON * 
@NETGUI 





if not %2 == RW GOTO DISKBOOT 
$1: \DOSLAN\NET\RPLTERM 
: DISKBOOT 





Figure 181. RIPL.BAT (modified for NETGUI) Invoked From STD_AUT.BAT 


Note: Any path extensions are to be made here. 
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t—— Messenger considerations 


Since a DOS Remote IPL starts from a redirected drive to which the Remote 
IPL requester only has READONLY access, you cannot start the messenger 
services before the [Messenger] section in the NETWORK.INI file is adapted. 
Per default logging will be done on the drive where DOS LAN Services has 
been started. Due to the fact that this is a READONLY drive, you must add, 
for example, following lines to the Remote IPL requester's NETWORK.INI file: 


[Messenger] 
Logfile=C: \MESSAGE. DAT 

















If the Remote IPL requester has a local drive, alternatively, you can log to a 
home directory if this is set up at the Remote IPL server. 











Creating a DOS Image from Diskette 
A DOS image can be, for instance, a reference diskette of a medialess Remote 
IPL machine. It usually is not necessary to create a DOS image from a diskette 
of installed DOS versions on the Remote IPL server. 
Use the following steps to create a DOS image from diskette: 
1. Insert the diskette in the source drive. 
. Open LAN Services from the Desktop. 


2 

3. Open LAN Server Administration. 
4. Open appropriate local workstation. 
5 


. Select Diskette Image Source (one click with the left mouse button on the 
icon). 


6. Press the right mouse button, and select Make image from Diskette... from 
the menu. 


The Make Image from Diskette window is displayed: 








ee 


fe 





A e 
Local Workstation ANYDOMO1 Shadowed Servers 


A 
A 
A 
A 
A 
A 
| 
A 








Ei 


services “3 Remote IPL Requesters bos Image | Definitions : 
- v Zy “Make image from Disketta’ 















Image name *R 










Target server * ANYSRVO1 


Source drive | * A 


Cancal | | 


SAARI 


ASS 
S 


Figure 182. Make Image From Diskette Window 
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Type the image name. 


Select the target server, which is the server where you want the image 
created. 


9. Select the source drive, which is the local diskette drive. 


. Select OK. 


LAN Server copies the image to the target server. 


Note: 


You can also perform this task from the command line using the 
MAKEIMG utility which has the following command syntax: 





--MAKEIMG- --d: outputfil _ == Soe SSSS5 
-/infile/Sxxxxxxxx--/Fyyy- 














Parameter Description 


d: outputfile Specifies the drive where the output file is located and its 
name The .IMG extension is added automatically. 


infile Specifies either a drive letter, where a disk formatted 
with the FORMAT /S command can be found, or the name 
of a definition file. 


ISXXXXXXXX Specifies a target server name. 


IFyyy Specifies an image diskette size where yyy can be either 
360, 720, 1.2 or 1.4. The default size is 720. 


Creating a DOS Image from a Definition File 
If DOS Remote IPL Support is installed, you can also create images from image 
definition files. 


Follow the following steps to create an image from a definition file. 


1. 


Open LAN Services folder from the Desktop. 


2. Open LAN Server Administration. 
3. 
4 
5 


Open the appropriate local workstation. 


. Open DOS Image Definitions. 


. Select the definition object (one click with the left mouse button on the icon) 


from which you want to make a DOS image. 


The following definition objects are supplied with OS/2 LAN Server 4.0: 





STDxyzZzz 


1 

! +-- can be either BAS which means basic redirector 
! or FUL which means full redirector 
! 
! 
! 














or HMA which means full redirector plus HMA support 
or UMB which means full redirector plus UMB support 














+---- can be either H which means 1.44 MB or 1.2 MB image 
or L which means 720 kB image 


+----- can be either 3 which means 3.5 inch 
or 5 which means 5.25 inch 
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Figure 183. DOS Image Definition window 


As shown in Figure 183, the DOS image definitions folder contains one 
object for each image definition that exists on the server. 


For example, select STDSHUMB to have the maximum amount of memory 
available at the Remote IPL client. All DLS network drivers will be uploaded 
into upper memory block (UMB). 


6. Press the right mouse button, and select the arrow to the right of Make 
image (See Figure 183). 


7. Select To Server. The Make Image to Server window is displayed which is 
shown in Figure 184. 








| Target server * 





Figure 184. Make Image to Server window 


8. Select the name of the target server, which is the server where the image is 
created. 


9. Select OK. 
The image is created and saved in the \IBMLAN\DCDB\IMAGES directory on the 
target server. 
Notes: 


The target server you specify creates the image. Therefore, the required IPL 
Image Support must be installed at the destination server. 


Remember, in this step, the STD_AUT.BAT and UMB_CFG.SYS will be 
included in the new created image. Therefore, if you have to make changes 
to these files, do it before you create the DOS image. Otherwise you have to 
recreate the DOS image. 
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Defining Windows as a Shared Application 
If you have uniform remote IPL workstations, that is if all machines use one 
display resolution and one printer type, you might define Windows as a shared 
application on your network. The following restrictions apply: 


User home directories must be set up for all remote IPL users to store 
Windows group files. 


No additional groups can be added to the program manager by the remote 
IPL user, so that the Windows desktop to be shared has to be set up by the 
administrator. 


Following is a suggestion on how to implement Windows as a shared application. 


1. 


Have a PC already installed with DOS and DOS LAN Services. From this PC, 
Windows will be installed remotely onto the server. 


. At the server create an alias name, for example, IBMLAN that points to 


C: IBMLAN (assuming C: is the drive on which LAN Server is installed). 


. At the client, log on to the domain with an user ID that has administrator 


privelegde level. 


. Assign the IBMLAN alias as a redirected Z: drive. For example issue the 


following command: 








NET USE Z: IBMLAN 














The Z: drive letter is used since remote IPL clients have the Z: drive as their 
boot drive on which DOS and DOS LAN Services reside. 


. Install Windows either from diskette or from a redirected drive. At the 


window where you will be prompted to, type a directory on which Windows 
will be installed, type: 





Z: DOSLAN WINDOWS 











. After successful installation of Windows, install all other Windows 


applications that the remote IPL user needs. Always select the Z: DOSLAN 
drive and directory to which the application must be installed. 


. Edit the Z: DOSLAN WINDOWS PROGMAN.INI file using an ASCII editor. 


Change the path for all group statements to the drive and directory assigned 
to the application. Usually it is the remote IPL user's home directory, for 
example: 





Group1=H: WINDOWS MAIN.GRP 
Group2=H: \WINDOWS\ACCESSOR.GRP 
Group3=H: \WINDOWS\GAMES .GRP 
Group4=H: \WINDOWS\ STARTUP .GRP 

















N 
N 














. Copy all group files to the remote IPL user's home directory. 


. Give RPLGROUP the proper access controls to the new subdirectories that 


you have created. For example, issue the following commands from the 
OS/2 command line: 

















NET ACCESS C: IBMLAN DOSLAN WINDOWS /ADD RPLGROUP:RX 
NET ACCESS C:\IBMLAN\DOSLAN\WINDOWS\SYSTEM /ADD RPLGROUP:RX 




































































Note: You need to have admin rights to issue the NET ACCESS commands. 
No /APPLY parameter is supported in this case since C: IBMLAN is a 
protected resource by the remote IPL process. 
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10. You may need to modify the HMA_CFG.SYS or UMB_CFG.SYS, 
STD_AUT.BAT and RIPL.BAT files which reside in the 
C: IBMLAN DOSLAN NET directory at the remote IPL server. 


-—— Enhanced Mode Consideration 


If remote IPL users need to run Windows in enhanced mode with Upper 
Memory Block (UMB) support, modify the following CONFIG.SYS 
statement in the IBMLAN\DOSLAN\NET\UMB_CFG. SYS file. 



























































DEVICE=A: \EMM386.EXE NOEMS /Y=Z:\DOSLAN\DOS\EMM3 86 .EXE 
































a. UMB_CFG.SYS file: Add the COUNTRY.SYS device driver if you need 
national language support. 


b. STD_AUT.BAT file: Add keyboard support for national language support 
and mouse support if necessary. 


c. RIPL.BAT file: Add Z: DOSLAN WINDOWS to the PATH statement. If you 
like, add the WIN command as last line. 





Find examples in “Create DOS IPL Images” on page 307. 


11. Create a DOS image from a defifition file as it is described in “Creating a 
DOS Image from Diskette” on page 310. 


12. Create DOS remote IPL clients from the LAN Server Administration GUI of 


LAN Services. (See “Create Workstation Records for the RPL.MAP File” for 
more information) 


Create Workstation Records for the RPL.MAP File 
The LAN Server Administration GUI offers an easy way to insert entries for: 
* DOS Remote IPL machines 


* OS/2 Remote IPL machines 
to the RPL.MAP file. At your Remote IPL server, open the LAN Services folder 
and select the folder Local Workstation by double-clicking its icon. Open the 


Remote IPL Requesters folder. An example of the opened folders is seen in 
Figure 185 on page 315. 
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Figure 185. Remote IPL Requester Definition 


By dragging the Remote IPL Requester Template icon to a free place and 
dropping the template within the same folder, you can define new Remote IPL 
requesters. The settings notebook will be opened. 


Create DOS Workstation Records for the RPL.MAP 
Prerequisites before defining DOS Remote IPL machines: 


- DOS IPL images must be created either: 
- From diskette or 
- From an image definition file 
If you have already created DOS IPL images, continue with the next steps. 
Otherwise, refer to “Create DOS IPL Images” on page 307. 


1. Select the radio button to determine that the selected Remote IPL 
workstation is enabled for DOS. 


Note: You can define a workstation as a requester twice - once as a DOS 
requester and once as an OS/2 requester. However, you can only 
enable one type of operating system at a time for Remote IPL. 


2. Type a name to identify the remote workstation to the network. The name 
should be different from user IDs and other computer names on the network. 


The following naming convention must be considered: 
* The name must have a minimum length of 1 character. 


* The maximum length of the machine ID is 8 characters because the 
selected operating system, DOS, cannot handle names longer that 8 
characters. 


Note: The machine ID cannot be modified after the requester definition is 
created. 


Chapter 13. Remote IPL 315 


3. Optionally, type a short description of the workstation to help identify this 
Remote IPL requester in a list. The description can contain up to 40 bytes. 

4. Type the network adapter address of the adapter you are using for the 
Remote IPL workstation. This must be the universal address. The address 
contains 12 hexadecimal characters. 


An example of possible entries is seen in Figure 186. 









PAV AES 


oO 


Machine ID * RPLDOSO1 





Deseription ITSCRPLWkstO1 | 


Network adapter address «© 10005A6F8293_ 


Figure 186. Create Remote IPL DOS Requester - Identity Settings 


5. Go to the Parameters settings. 


6. To determine the value of the record identifier, click on the down arrow to 
display a list of valid server-record identifiers and select one. 


The server-record identifier resides in the workstation record and identifies 
the workstation's corresponding server record in the RPL.MAP file. 


7. Specify Image ID. To select an image ID, click on the down arrow to display 
a list of valid DOS images and select one. 


An example of possible entries is seen in Figure 187 on page 317. 
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Figure 187. Create Remote IPL Requester - Parameters Settings 


8. Optionally, enter data in the Menu settings page. 

9. Optionally, enter a title in the General settings page. 

10. Select Create now. 
While creating the new Remote IPL requester, the following changes have been 
made: 


* A new record in the workstation records section of the RPL.MAP file 
(compare with Figure 169 on page 289) has been made with the following 
entry: 


; workstation records 
10005A6F8293 RPLDOSO1 ~ STD3HUMB ANYSRVO1 ANYDOMO1 ~ ~ ~ ,,, ZR_DTK_NDIS ~ ~- 





Figure 188. Workstation Record Entry for a Remote IPL DOS Client 


* A Remote IPL subdirectory for the Remote IPL DOS requester was created in 
IBMLAN RPLUSER RPLDOSO1. 


Create OS/2 Workstation Records for the RPL.MAP 
1. As shown in Figure 185 on page 315 drag a Remote IPL Requester Template 
to a free place and drop the template within the same folder. 


i) 


. At the settings notebook select one radio button to determine whether and 
with what operating system the selected Remote IPL workstation is enabled. 
In this case enable the workstation as an OS/2 requester. 

Note: You can define a workstation as a requester twice - once as a DOS 


requester and once as an OS/2 requester. However, you can only 
enable one type of operating system at a time for Remote IPL. 


o 


. Type a name to identify the remote workstation to the network. The name 
should be different from user IDs and other computer names on the network. 
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The following naming convention must be considered: 
* The name must have a minimum length of 1 character. 


* The maximum length of the machine ID is 15 characters when the file 
system installed on the Remote IPL server is HPFS. 


* The maximum length of the machine ID is 8 characters when the file 
system installed on the Remote IPL server is FAT. 


Note: The machine ID cannot be modified after the requester definition is 
created. 


4. Optionally, type a short description of the workstation to help identify this 
Remote IPL requester in a list. The description can contain up to 40 bytes. 


5. Type the network adapter address of the adapter you are using for the 
Remote IPL workstation. This must be the universal address. The address 
contains 12 hexadecimal characters. 


An example of possible entries is seen in Figure 189. 


oS 


Machine ID 
Description 


Network adapter address 









a 


q 
Cancel ; 





SSSA arora rnin marino Aa aa AMAA AMA AMAA AAA 





Figure 189. Create Remote IPL OS/2 Requester - Identity Settings 


6. Go to the Parameters settings. 


7. To determine the value of the record identifier, click on the down arrow to 
display a list of valid server-record identifiers and select one. 


The server-record identifier resides in the workstation record and identifies 
the workstation's corresponding server record in the RPL.MAP file. 


8. Specify Remote IPL Boot Drive. To select a drive, click on the down arrow to 
display a list of valid drives and select one. The default is Z. 


Note: Do not specify drive A or B or a local hard-disk drive (for example, C 
or D) for the boot drive. 


An example of possible entries is seen in Figure 190 on page 319. 
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Figure 190. Create Remote IPL Requester - Parameters Settings 
9. Optionally enter data in Menu settings page. 

10. Optionally enter a title in the General settings page. 
11. Select Create now. 


While creating the new Remote IPL requester, the following changes have been 
made: 


* A new record in the workstation records section of the RPL.MAP file 
(compare with Figure 169 on page 289) has been made with the following 
entry: 







; workstation records 
10005A1D2F04 OS2RIPLO1 ~ FITS\OS2RIPLO1 ANYSRVO1 Z ~~~ ,,, ~ R_21_OTK ~ ~ ~ 


Figure 191. Workstation Record Entry for a Remote IPL OS/2 Client 


+ System-specific files for the Remote IPL OS/2 requester were created as 
follows: 
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8-25-94 
8-25-94 








8-25-94 
8-25-94 
8-25-94 


11-02-93 
11-10-93 
4-24-93 
4-24-93 
8-07-94 
4-26-93 
8-07-94 
4-24-93 
4-24-93 
4-24-93 





8-07-94 11:29a 


Directory of C:\IBMLAN\ 


Directory of C:\IBMLAN\ 


Directory of C:\IBMLAN\ 


Directory of C:\IBMLAN\ 


Directory of 


Directory of C:\IBMLAN\RPL\MACHINI 
0 CONFIG.SYS 





7:10p 2656 
7:10p 1748 
1457 0 


Directory of C:\IBMLAN\ 
2417 


7:10p 
































ES\OS2RIPLO1 


0 CONFIGRI.SYS 


PROTOCOL. INI 






































Figure 192. Remote IPL OS/2 Workstation Specific Files 


RPL\MACHINES\OS2RIPLO1\IBMLAN 
0 IBMLAN. INI 





Note: Since the file system of the Remote IPL server is HPFS, the 


workstation's name length is allowed to be up to 15 characters. 


Additional Considerations: Resynchronization of NET.ACC 


If a Remote IPL workstation definition is deleted from an Additional Server or 
Backup Domain Controller, a new definition using the same workstation name 
cannot be created until the domain controller has resynchronized the NET.ACC 
file. Any attempt to recreate the workstation definition prior to the 
resynchronization will result in following message: 





NET5421: The machine definition already exists on the Remote 





The synchronization time interval is controlled by the PULSE parameter in the 
domain controller IBMLAN.INI file. 


Remote IPL Configuration Utility RPLSETD 


In comparison to the RPLSETD utility provided with the OS/2 LAN Server 3.0 
product, the new RPLSETD utility provides these main functions: 


+ Upgrades existing Remote IPL clients from using 16-bit display drivers to 
using the new 32-bit VGA, XGA, and 8514 display drivers provided in OS/2 


2.11. 


4:41p 281 0 AUTOEXEC.BAT 
RPLUSER\OS2RIPLO1\IBMLAN\ACCOUNTS 

:13p 37888 0 NET.ACC 
RPLUSER\OS2RIPLO1\IBMLAN\NETPROG 

6:29p 118162 0 NETGUI.INI 
RPLUSER\OS2RIPLO1\0S2 

2:20p 21122 0 OS2.INI 

2:20p 17079 0 OS2SYS.INI 

2:20p 147 0 REINSTAL. INI 

C: \IBMLAN\RPLUSER\OS2RIPLO1\0S2\MDOS\WINOS2 

7:08p 460 0 ATM.INI 

5:10p 3943 0 CONTROL. INI 

6:33p 28 0 MOUSE. INI 

7:03p 621 0 MSD.INI 

11:28a 323 0 PROGMAN. INI 

4:57p 44 0 STARTUP.GRP 

iis29a: 1771 0 SYSTEM. INI 

6:29p 3949 0 WIN.INI 

7:12p 13538 0 WOS2ACCE.GRP 

7:12p 5091 0 WOS2MAIN.GRP 








IPL server. 


+ Changes the display type (32-bit VGA, XGA, or 8514) that a Remote IPL client 


is using. 
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Updates a Remote IPL client to change the bus type, as in MCA or ISA/EISA. 
The Remote IPL client's file index table and CONFIG.SYS will be updated 
correctly for ISA specific drivers. 


+ Updates a Remote IPL client to specify whether the SWAPPATH and WIN-OS/2 
paging file is on a local hard disk or on the Remote IPL server. 


This utility has the following command syntax: 











--RPLSETD --- — /C:client-- - - 














/H: /R:responsefil 


---/L:logfil ss Bah ld aera Sade RN ey ue Ba 








| =8- | 














| -ISA-- | 

| -EISA- | 

-/D:displaydriver - - = = = = = 

- = o -—7N:newos2dir--/D:displaydriver- 

| -/O:currentos2dir- | 
/I---- ~---------------- ~-------------- 





























Parameter Description 


/C:client1, client2, clients... 
Equivalent to the CLIENT and CLIENTLIST response file keywords. 
Specifies the name of one or more OS/2 Remote IPL client 
workstations that are to be updated. If multiple client names are 
specified, each client name must be separated with a comma. 
Imbedded blanks are not allowed. The response file keywords 
CLIENT and CLIENTLIST are equivalent to each other. You can 
specify them as many times as necessary. This is a required 
parameter if the /R parameter is not specified. When /R is 
specified, at least one other parameter must also be specified. 





















































/H: Displays the syntax on the screen. If specified, it must be the 
first parameter. 


/R:responsefile Specifies the drive, path, and file name of a file that contains the 
command inputs in keyword form (keyword=value). Each 
keyword corresponds to one of the RPLSETD syntax parameters 
as indicated in this section. For more information about the 
response file, see “Response File for the RPLSETD utility” on 
page 325. Only one keyword can be specified per line in the 
response file. The /C parameter and at least one other 
parameter are required when using a response file. If the /R 
parameter is specified, all other parameters specified on the 
command line are ignored. 


/L:logfile Specifies the drive, path, and file name of a file to which all 
messages and errors are to be logged. If this parameter is 
specified, the only errors displayed on the screen are for a 
failure to open the log file or for required parameters missing 
from the response file. 


/O:currentos2dir 














Equivalent to the CURRENTOS2DIR response file keyword. Specifies 
the root directory under \IBMLAN\RPL for the current version of 
OS/2 2.x that the client is using. This parameter is 
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/N:newos2dir 


/D:displaydriver 
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case-sensitive. Specify the /O parameter only when you want 
the client operating system type verified before updating to a 
new operating system type. If you do not specify /o, the current 
operation system being used by the Remote IPL client is 
determined from the CLIENT.FIT file. If you do specify /0, you 
must also specify /N. 

















Equivalent to the NEWOS2DIR response file keyword. Specifies the 
root directory under \IBMLAN\RPL or the version of OS/2 2.x to 
which the client is to be switched. This parameter is 
case-sensitive. The default is O0S2.21. Specify the /O and /N 
parameters only when you need to switch a client from one OS 
version to another OS version. When an existing Remote IPL 
client is updated to OS/2 2.1, you must replace the client 
WINOS2 *.INI and *.GRP files with the 2.1 versions of these files. 
The old files are renamed to *.IBK and *.GBK. When these old 
files are no longer needed for reference, delete them. 





Equivalent to the DISPLAYDRIVER response file keyword. Specifies 
the new display type for the client definition. The following 
display types are valid: 




















* VGA or IBMVGA32 VGA display driver 
* XGA or IBMXGA32 XGA display driver 
* 8514, IBM8514, or 8514_32 8514 display driver 
SVGA SVGA display driver for non-S3 
chip sets (OS/2 2.11) 
S3SVGA SVGA display driver for S3 chip 


sets (OS/2 2.11) 


Note: The SVGA support requires that OS/2 2.11 support files 
be installed prior to using RPLSETD. For information 
about installing OS/2 2.11 SVGA support files, see 
“Configure a Remote IPL Requester for SVGA” on 
page 324. 


The appropriate 16-bit or 32-bit display driver for each 
display type is determined based on the version of OS/2 
being used by the client. 


This parameter is normally optional. However, it must be 
specified when an existing 2.0 or 2.00.1 Remote IPL client 
is converted to 2.1 by specifying the /N parameter. 


When upgrading the display type of an existing Remote 
IPL client (when it has booted at least one time and has a 
Desktop) from VGA to XGA or 8514, you must delete and 
recreate the Remote IPL client and then run RPLSETD. If 
you update the existing client to a higher resolution 
display type, many of the display sizing characteristics in 
OS2.INI do not get updated. As a result, some objects are 
in VGA resolution and some are in the higher resolution. 
If no desktop exists for the client, the Desktop can be 
updated to change to a higher resolution. When the 
Desktop is created during the first boot, the Desktop 


reflects the display characteristics for which it is 
configured. 


IB: Equivalent to the BUSTYPE response file keyword. Specifies the 
type of I/O bus used by the Remote IPL client machine. Valid 
types are: 


MCA Micro Channel 
* ISA AT compatible 
EISA AT compatible 





IS: Equivalent to the SWAPTARGET response file keyword. Specifies the 
location where the SWAPPER.DAT file is to reside. The following 
values are valid: 





L The file is to reside on the local hard disk of the 
Remote IPL client. 


S The file is to reside on the Remote IPL server. 


A Displays a message indicating the current configuration (display 
type, bus type, and swap target) of the Remote IPL clients 
specified by the /C parameter. When /T is specified, all other 
parameters except /C are ignored. 





Notes: 


1. Client definitions can be updated individually or in a group (grouped by 
common attributes such as display type, bus type, and operating system). 


2. The client names DEFALT20 and DEFALT21 are reserved. Do not create a 
client using either of these names. Do not attempt to update the DEFALT20 or 
DEFALT@1 clients with RPLSETD. 


3. If a Desktop exists, use the RPLSETD utility to change to the higher 
resolution display type. Then perform an IPL on the client and let it create a 
new Desktop (changing the old Desktop could result in unpredictable 
results). 


Examples of using the RPLSETD command: 


The following example updates the OS2RIPLO1 client to use the 32-bit XGA 
display driver: 








RPLSETD /C:OS2RIPLO1 /D: IBMXGA32 




















The following example updates the OS2RIPLO1 client to use the 32-bit XGA 
display driver, verifies that the current operating system is OS/2 2.0, and 
switches the operating system to OS/2 2.1: 








RPLSETD /C:O0S2RIPLO1 /D:IBMXGA32 /0:0S2.20 /N:0S2.21 























The following example updates the OS2RIPLO1 client to specify a bus type of ISA 
and sets the SWAPPATH/PagingFile to the Remote IPL server: 


RPLSETD /C:O0S2RIPLO1 /B:ISA /S:S 


























The following example updates the OS2RIPLO1 client to use the 32-bit VGA 
display driver, verifies that the current operating system is OS/2 2.0, switches 
operating system to OS/2 2.1, specifies a bus type of ISA, and sets the 
SWAPPATH/PagingFile to the Remote IPL server: 


RPLSETD /C:OS2RIPLO1 /D:IBMVGA32 /0:0S2.20 /N:0S2.21 /B:ISA /S:S 
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The following example updates multiple clients, OS2RIPLO1 and OS2RIPLO2, to 
use the 32-bit VGA display driver and switches the operating system to OS/2 2.1: 



































RPLSETD /C:OS2RIPLO1,O0S2RIPLO2 /D: IBMVGA32 /N:0S2.21 


Configure a Remote IPL Requester for SVGA 
1. Prior to performing the RPLSETD command, you have to install the SVGA 
*.DSP files in the RIPL directory tree. To do so, run the following 
ClD-enabled REXX procedure from an OS/2 command line to install the 
SVGA support files: 


--RPLSVGAI = -- - - —— See = 








poh ears -/S:Source- -/L:Logfile- 
-/H- 


Parameter Description 


2? or /H Specifies a request for this help panel. If specified, it must be the 
first parameter. 


/S:Source Specifies the source from which to load the SVGA support files. 
Source can be a diskette drive (that is, A or B, do not specify the 
colon) or a redirected LAN drive/path for example the CID code 
server drive: d: IMG 0S2V211. The default value is drive A. 


/L:Logfile Is the fully qualified name of a file to which all messages and 
errors are to be logged. If logfile is specified, no messages or 
errors will be displayed on the screen. 


You can issue the command without passing parameters, if there is no OS/2 
version other than OS/2 2.11, to support for Remote IPL. 


2. After successful completion of the RPLSVGAI utility, use the RPLSETD 
command to change the display driver. 


Now, for example, to configure an ISA bus machine called OS2RIPLO1, use 
the following command: 


For ISA bus machines that have an SVGA adapter based on S3 
technology: 





RPLSETD /C:O0S2RIPLO /D:S3SVGA /B:ISA 











For ISA bus machines that have a non-S3 SVGA adapter: 
RPLSETD /C:O0S2RIPLO /D:SVGA /B:ISA 
Note: When the /D:SVGA or S3SVGA option is specified, the RPLSETD utility 
does not configure the workstation for SVGA. It modifies the 


workstation definition so that the workstation can run the OS/2 SVGA 
install procedure DSPINSTL. 












































Configuring a workstation for SVGA moves the workstations 
CONFIG.SYS file from the RPL MACHINES requester_name directory 
to the RPLUSER requester_name directory. 

At the Remote IPL requester perform the following steps: 


1. Start the Remote IPL workstation. 





2. At an OS/2 window, run the DSPINSTL command. 








This command starts the OS/2 SVGA installation program. The Display 
Driver Install window is displayed. 
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14. 
15. 


16. 
17. 


. Select Primary Display, and then select OK. 


The Primary Display Adapter Type window is displayed. The SVGA adapter 
detected is highlighted. 


. Select the highlighted adapter, and then select OK. 


The Monitor Configuration/Selection Utility window is displayed. 


. Select Install Using Defaults for Monitor Type and then select OK. 


The screen will appear blank for a few seconds and then either a Screen 
Resolution Selection window or the Source Directory window is displayed. 


. If the Screen Resolution Selection window is displayed, select the 


appropriate resolution. 


. Select Change Source Directory. 


The Select Directory window is displayed. 


. Select the Remote IPL workstation boot drive ID. The default boot drive ID is 


Z unless it was changed when the requester was created. 


. Select OS/2. 
. Select DISP. 
. Select Set. 


The Source Directory window still is displayed. 


. Select Install. 


A Display Driver Install information window is displayed indicating that 
shutdown is required before the changes become effective. 


. If non-S3 SVGA support was installed, shut down the system and restart it. 


For S3 SVGA support, continue with the following steps. 
Open the System Setup folder. 

Open System by double-clicking on its icon. 

The System Settings notebook is displayed. 

Select the display resolution you want. 


Shut down and restart the system to use the new display support. 


Response File for the RPLSETD utility 
Instead of issuing the RPLSETD command for each client to be altered, a quicker 
way may be to issue the RPLSETD command along with a response file. 


The following entries and keywords are valid in the response file for the 
RPLSETD utility: 
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; Comment line 

[GROUP] 

; the previous statement is optional for the first group and required 
; for all subsequent groups 


DISPLAYDRIVER= 
CLIENT= 
CLIENTLIST= 

CURRENTOS2DIR= 
NEWOS2DIR= 
BUSTY PE= 
SWAPTARGET= 



































Figure 193. Response File for the RPLSETD Utility 


The [GROUP] statement designates the start of a Remote IPL client or a group of 
clients that share the same configuration characteristics. When the [GROUP] 
statement is encountered, the client machines in the previous group are updated 
according to the specified keywords. Multiple [GROUP] statements can be used in 
the response file. Having multiple [GROUP] statements allows a single response 
file to process a number of different configurations. The [GROUP] statement is 
optional for the first group in the response file, but it is required for all 
subsequent groups. 




















CLIENT and CLIENTLIST are equivalent, and multiple entries can be specified on 
either. Multiple CLIENT and CLIENTLIST keywords can be specified per group. 
Only one of each of the other keywords is allowed per group. 






































A semicolon (;) in column 1 indicates the line is a comment. Leading blanks are 
allowed on keyword statements. 


Example: 


[GROUP] 

CLIENT=DEFALT20 
CLIENT=OS2RIPLO1,O0S2RIPLO2 
CLIENTLIST=OS2RIPLO3 ,OS2RIPLO4 
DISPLAYDRIVER=IBMXGA3 2 
CURRENTOS2DIR=O0S82.20 
NEWOS2DIR=0S2.21 

BUSTY PE=MCA 

SWAPTARGET=L 


























[GROUP] 
CLIENT=OS2RIPLO5 
BUSTYPE=ISA 
SWAPTARGET=S 














Figure 194. Example Response File for the RPLSETD Utility 


Using this response file, type the following command and press Enter: 














RPLSETD /R:d: path response_filenam 





where d: path response_filename is the fully qualified file name of the response 
file. 


Explanation of the response file example: 
In the first [GROUP] section, the mentioned clients will get an update to support 


the IBMXGA2z2 display driver, will be switched from OS2.20 to OS2.21, get MCA 
bus support, and the swappath will be put on a local hard disk. 
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In the second [GROUP] section, the mentioned client will get an update for ISA bus 
support and the swappath will be put on the RIPL server (no local hard disk). 


Updating FIT Files for OS/2 Remote IPL Workstations 


The file index tables (FIT) provided with the OS/2 LAN Server 4.0 product 
includes Remote IPL support for the associated OS/2 operating system. 

Although there are entries that point to other products, like Communications 
Manager/2 and Database 2 for OS/2, an update of the FIT files is necessary if 
you want to use these products in a Remote IPL environment. Also, if ISA or 
EISA machines have to be supported for Remote IPL, an update of the FIT tables 
is necessary as well since the provided FIT tables only support Micro 
Channel-based machines. In this case, this can be easily done by using the 
RPLSETD utility. “Remote IPL Configuration Utility RPLSETD” on page 320 
shows how to do it. 


Example: RIPL Update for Communications Manager/2 Support 
As a prerequisite for Remote IPL CM/2 support, CM/2 is installed and configured 
on the Remote IPL server. 


If you generally want to use Communications Manager/2 on all remote IPL 
clients, you must update the standard FIT tables that come with the product. If 
only specific Remote IPL clients are supposed to use Communications 
Manager/2, you need to create another workstation record, and use the new 
record as a pattern for other Remote IPL workstations. 


In this example the standard FIT table DEFALT21 is used for the CM/2 update. 
You have to adapt the workstation name according to your needs as mentioned 
before. 


Assuming CM/2 has been installed on the C: drive completely, and the Z: drive is 
the Remote IPL client's startup drive, issue the following commands to enable 
CM/2 for Remote IPL clients: 








1. Create a CMLIB subdirectory in the IBMLAN RPL directory for example: 


























MD C: IBMLAN RPL CMLIB 
2. Copy the whole CM/2 product to the RIPL tree. 
XCOPY C: CMLIB C: IBMLAN RPL CMLIB /S /E /V 









































Assuming CM/2 must be enabled to all Remote IPL clients the template file 
index tables (in the FITS directory as shown below) must be modified. 
Depending on the operating system, this is: 








BMLAN RPL FITS DEFALT20.FIT 
\ IBMLAN\RPL\FITS\DEFALT21.FIT 
\IBMLAN\RPL\FITS\DEFALT230.FIT 


3. Edit the adequate FIT file (in this example, it is the OS/2 2.1 FIT file): 




































































a. In the Communications Manager/2 section, delete the following lines: 





Z:\CMLIB\LOG$ \\ANYSRV01\WRKFILES\DEFALT21\CMLIB\LOGS$ 
Z:\IBMCOM\cfgname.INI \\ANYSRV01\WRKFILES\DEFALT21\IBMCOM\cfgname. INI 











b. In the Communications Manager/2 section, change the following lines: 
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4. Create a CMLI 
example: 


NNNNWN 


NNNNWN 


: \CMLIB\APPN\* .NDF 
: \CMLIB\APPN\* .CF2 
: \CMLIB\APPN\* .SEC 
: \CMLIB\APPN\* . LOG 
: \CMLIB\APPN\* .Z2Z 





: \CMLIB\* .NDF 
: \CMLIB\* .CF2 
: \CMLIB\* . SEC 
: \CMLIB\* .LOG 
: \CMLIB\* .Z2ZZ 
















































































In the section for writable files, add these lines: 


Z 
Z 


\\ANYSRV01\WRKFILES \DEFALT21\CMLIB\APPN 
\\ANYSRV01\WRKFILES \DEFALT21\CMLIB\APPN 
\\ANYSRV01\WRKFILES\DEFALT21\CMLIB\APPN 
\\ANYSRV01\WRKFILES\DEFALT21\CMLIB\APPN 
\\ANYSRV01\WRKFILES\DEFALT21\CMLIB\APPN 





\\ANYSRV01\WRKFILES \DEFALT21\CMLIB 
\\ANYSRV01\WRKFILES \DEFALT21\CMLIB 
\\ANYSRV01\WRKFILES \DEFALT21\CMLIB 
\\ANYSRV01\WRKFILES \DEFALT21\CMLIB 
\\ANYSRV01\WRKFILES\DEFALT21\CMLIB 





:\OS2\SYSTEM\LOGO001.DAT \\ANYSRVO1\WRKFIL 
:\OS2\SYSTEM\LOGO001.BAK \\ANYSRV0O1\WRKFIL 
































In the Communications Manager/2 section, add the following lines: 


NNNNNNNNNNNNNNNNWN 


: \CMLIB\*.000 
: \CMLIB\ACSRASTD. 
: \CMLIB\ACSRASTD. 
: \CMLIB\ACSRASTD. 
: \CMLIB\CM. INI 
: \CMLIB\CM2 . INI 
:\CMLIB\CM2.!!! 
:\CMLIB\CM2 . ## 
: \CMLIB\ALRTNPOP. 
:\OS2\EPW. INI 
:\OS2\EPW.!!! 
:\OS2\EPW. ### 
:\OS2\VPD. INI 
:\OS2\VPD.!!! 
:\OS2\VPD. ### 











: \OS2\SYSTEM\OS2MLOG. DAT 








: \OS2\SYSTEM\* . DMP 


INI 
at 


HEF 


TXT 


[B subdirectory in the 











\\ANYSRV01\WRKFILES\DEFALT21\CMLIB 








\\ANYSRV01\WRKFIL 


ES\DEFALT21\CMLIB\ACSRASTD. 








\\ANYSRV01\WRKFIL 


ES \DEFALT21\CMLIB\ACSRASTD. 

















\\ANYSRV01\WRKFIL 


ES\DEFALT21\CMLIB\ACSRASTD. 











\\ANYSRV01\WRKFIL 


ES\ 





DEFALT21\CMLIB\CM. 








\\ANYSRV01\WRKFIL 


ES \DEFALT21\CMLIB\CM2 








\\ANYSRV01\WRKFIL 





ES \DEFALT21\CMLIB\CM2 





\\ANYSRV01\WRKFIL 








ES \DEFALT21\CMLIB\CM2 











\\ANYSRV01\WRKFIL 














ES\DEFALT21\CMLIB\ALRTNPOP. 














\\ANYSRV01\WRKFILES\DEFALT21\0S2\EPW. INI 





\\ANYSRV01\WRKFILES\DEFALT21\0S2\EPW. ! 











\\ANYSRV01\WRKFILES\DEFALT21\0S2\EPW. # 











\\ANYSRV01\WRKFILES\DEFALT21\0S2\VPD. 





\\ANYSRV01\WRKFILES\DEFALT21\0S2\VPD. ! 














\\ANYSRV01\WRKFILES\DEFALT21\0S2\VPD. # 








\\ANYSRV01\WRKFILE 














\\ANYSRV01\WRKFILES 











\DEFALT21\0S2\SYST: 


INI 


ES \DEFALT21\0S2\SYSTEM\LOGO001.DAT 
ES \DEFALT21\0S2\SYSTEM\LOGO001 .BAK 


INI 
feel 


HEF 





INI 

- INI 

aaatsl 

HEF 

TXT 


# 





## 





S\DEFALT21\0S2\SYSTEM\OS2MLOG. DAT 


EM\* . DMP 























MD C: \IBMLAN\RPLUSER\DEFALT21\CMLIB 











5. Copy the following files, as shown in Figure 195. 


BMLAN RPLUSER DEFALTxx directory, for 





from: 





\CMLIB\CM. INI 
\CMLIB\CM2 . INI 
\CMLIB\ALRTNPOP. TXT 
\CMLIB\* .DAT 
\OS2\EPW* . * 
\OS2\SYSLEVEL.EPW 
\OS2\MSGLOGF . EXE 
\OS2\DLL\EPW* . * 
































to: \ IBMLAN\RPLUS 








ER\DEFALT21\CMLIB 














\ IBMLAN\RPLUSE 


R\ DEFALT21\CMLIB 














\ IBMLAN\RPLUS 


ER\ 


DEFALT21\CMLIB 











\ IBMLAN\RPLUSER\D. 


EFALT21\CMLIB 








\IBMLAN\RPL\OS2.21\0S2 


\IBMLAN\RPL\OS2.2 


1\0s2 





\ IBMLAN\RPL\OS2 .21\0S2 
\ IBMLAN\RPL\OS2 .21\0S2\DLL 








Figure 195. Additional CM/2 Files for Remote IPL Clients 


6. Edit the 


drive letter to the Remote IPL startup drive letter (usually Z:). 


7. Update the RIPL workstation OS2.INI, VPD,INI, and EPW.INI files with FFST/2 
configuration information. You can update the OS2.INI file with one of two 
methods: 


* Select Options from the Communications Manager Setup window and 
then select Recreate folders .... 


Inside OS/2 LAN Server 4.0 


IBMLAN RPLUSER DEFALT21 CMLIB CM.INI file and change the 


Use the RIPLINI productivity aid. RIPLINI is included with RINST2CM and 
it resides on the first Productivity Aids diskette of CM/2. 


8. Give RPLGROUP the proper access controls to the new subdirectories that 
you have created. For example, issue the following commands from the 
OS/2 command line: 





























NET ACCESS d: IBMLAN RPL CMLIB /ADD RPLGROUP: RX 
NET ACCESS d:\IBMLAN\RPL\CMLIB /APPLY 



































Note: You need to have admin rights to issue the NET ACCESS commands. 


9. The CONFIG.SYS templates for the different OS/2 versions reside the the 
IBMLAN RPL MACHINES subdirectory. Dependent on the operating system 
being used edit the appropriate CONFIG.DEF file. For example: 

















EPM IBMLAN RPL MACHINES DEFALT30 CONFIG. DEF 
































a. Add Z: CMLIB DLL to the LIBPATH statement. 


























b. Add Z: CMLIB to the SET PATH statement. 
c. Add Z: CMLIB to the DPATH statement. 
d. Add Z: CMLIB to the SET HELP statement. 

















e. Add Z: CMLIB BOOK to the SET BOOKSHELF statement. 





f. Add the following statements as last lines: 





SET CMPATH=Z: CMLIB 
DEVICE=Z: \CMLIB\CMKFMDE. SYS 
































g. To enable logging, add the following statements: 








DEVICE=Z: OS2 LOG.SYS 
DEVICE=Z: \OS2\EPWDD.SYS 

RUN=Z : \OS2\SYSTEM\LOGDAEM. SYS 
RUN=Z: \OS2\EPW. EXE 
RUN=Z: \OS2\EPWOUT.EXE 1 
RUN=Z: \OS2\EPWDDR3 . EXE 










































































10. Now remember, since the CONFIG.SYS file is built dynamically while creating 
a Remote IPL client, (refer to “Understanding OS/2 Server Record Identifier’ 
on page 291 for more information about dynamic build of CONFIG.SYS) 
change to the LAN adapter specific directory, for example 
C: IBMLAN RPL IBMCOM TOKENRNG and edit the CONFIG.NET file. 


























After the DEVICE=Z: ITBMCOM PROTOCOL NETBIOS.OS2 statement, add the following 
































lines: 














DEVICE=2Z: CMLIB ACSLANDD.SYS 
RUN=Z : \IBMCOM\PROTOCOL\NETBIND. EXE 





















































11. Create your Remote IPL clients from the graphical user interface of LAN 
Services or via command line. For example, create a Remote IPL client 
named OS2RIPLO1. 


12. Run CMSETUP at your Remote IPL server, and create configuration files for 
your Remote IPL clients. 


a. When you are asked if the configuration file will be used for your 
workstation, select No. 


b. Create the configuration file as you would for a typical CM/2 workstation. 
For example, create the configuration file ITSCWKO1. 
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13. At the OS/2 command prompt, copy the created CMLIB ITSCWKO1.* files to 
the adequate Remote IPL user directory, in our example 
IBMLAN RPLUSER OS2RIPLO1. 


14. Edit the file IBMLAN RPLUSER OS2RIPLO1 CMLIB CM.INI to change the file 
name that follows the text CMDefaultCFG= to ITSCWKO1. 


15. CMSTART is the command at the Remote IPL client to start CM/2. 





Note: Do not use the RIPL applets provided with the Communications 
Manager/2 Productivity Aids Diskette 1. They do not work with OS/2 LAN 
Server 4.0. 


Updating Master Workplace Shell OS2.INI Files 


Some users have a customized master OS2.INI file that is copied to the 
requester directory each time the requester is started with Remote IPL. This 
master file must also be updated to identify the type of display driver that the 
requester workstation is using. Requesters with different display types (for 
example, VGA, XGA, or 8514) must use different master OS2.INI files. 


To update a master OS2.INI file, enter the following command: 

















--RPLRXUTLD: Display—Driver--C: INI-File—Nam SSS S345 5268555555 














where D:Display_Driver is the same parameter as used for the RPLSETD 
command and C: INI_File_Name is the drive, path, and filename of the master 
OS2.INI file to be updated. 























For example: 








RPLRXUTL /D: IBMVGA32 /C:C: IBMLAN RPL MASTER VGAOS2.IN 





























The RPLRXUTL utility does not display error information, but does display a 
non-zero return code if an error occurs. If you need to verify error information, 
start RPLRXUTL from a CMD procedure (batch file or REXX) so that the return 
code can be tested. 


RPLADD Utility 


One of the applets delivered with OS/2 LAN Server 4.0 on the Productivity Aids 
diskettes is the RPLADD utility. It can be used to create Remote IPL client 
definitions from an OS/2 command line from any OS/2 workstation within the 
same domain. The local workstation and the target Remote IPL server must 
both be running OS/2 LAN Server 4.0 The local workstation must be logged on 
with administrator-level privilege. The remoteboot service does not have to be 
started at the target Remote IPL server. 


The syntax of the RPLADD utility is: 














--RPLADD-/F: input—filenam --------- - ---- --- 
-/O:output—log—filename- - /DEBUG- 











Parameter Description 


/F:input_filename This required parameter specifies the path and file name of 
the source input file containing the formatted records that will be 
used as input to the RPLADD.EXE program. See Table 20 on 
page 331 for an explanation of the input file format. 
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/O:output_log_filename This optional parameter specifies the path and file name 
of an output log file that will be used to record all output from the 
RPLADD.EXE program. If this parameter is specified, all output that 
would normally be displayed on the display, will be redirected to a 


file. 


/DEBUG This optional parameter is specified to display additional debug 
information about the execution of the RPLADD.EXE program. This 
parameter can be useful for displaying information about the 
parameters that are parsed from the input file. 


RPLADD Input File Example 
























































Figure 196. RPLADD Input File Example 


Field Field Name 


1 CREATE TYPE 
2 NAME 


3 ADAPTER ADDRESS 
4 SERVER RECORD 
IDENTIFIER 


5 OS/2 DRIVE 


Note: Use this 
parameter for OS/2 
machine definitions 
only! 


Table 20 (Page 1 of 2). Explanation of the RPLADD Input File Parameters 



































NAME ADAPTER SERVER RECORD OS/2 OS/2 DOS MODEL [SERVERNAME ] 
ADDRESS IDENTIFIER DRIVE CONFIG IMAGE NAME (Optional) 
OS2_MACH 100063870001 R_21_OTK Z LI3 
DOS_MACH 10005A222222 R_DTK STD3HFUL 
NEW_MACH 10005A333333 MODEL_MACH RIPL_SERV 








Explanation 


CREATE TYPE = 2 is specified to create a new machine 
definition and will inherit the default machine configuration. 


CREATE TYPE = 12 is specified to create a new machine 
from an existing model machine definition. The new 
machine will inherit all of the configuration files from the 
model machine definition. 


The name of the new Remote IPL machine definition. The 
machine name must be a unique name within the Domain. 
See “Create DOS Workstation Records for the RPL.MAP” 
on page 315 and “Create OS/2 Workstation Records for the 
RPL.MAP” on page 317 for more details about naming 
conventions. 


The ADAPTER ADDRESS is the 12 character universal 
adapter address of the Remote IPL machine. 


The SERVER RECORD IDENTIFIER specifies the operating 
system plus network adapter type configuration information. 


The OS/2 DRIVE specifies the boot drive letter for the OS/2 
Remote IPL machine. It must not be a local drive on the 
Remote IPL client. 





6 OS/2 CONFIG 


Note: Use this 
parameter for OS/2 
machine definitions 
only! 








The OS/2 CONFIG parameter is used to specify OS/2 
configuration parameters for the OS/2 Remote IPL machine. 
A combination of 3 flags are to be specified, one from each 
of the 3 categories. 


L = SWAPPER.DAT local 
SWAPPER.DAT on server 
Bus Architecture ...: I = ISA / EISA 
Microchannel 

~...e2..: 3 = S-3 Super VGA 
8514 display 

EGA display 

non S-3 Super VGA 
VGA display 

= XGA display 


SWAPPER. DAT 














Display type 
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Table 20 (Page 2 of 2). Explanation of the RPLADD Input File Parameters 


Field Field Name Explanation 














7 DOS IMAGE The DOS IMAGE specifies the DOS image file for the 
: ; Remote IPL machine. An image file extension of .IMG is 
Note: Use this 
parameter for DOS sesumed: 
machine definitions 
only! 

8 MODEL NAME The MODEL NAME specifies the Remote IPL client from 
which the new machine will inherit all the configuration 
information. 

9 SERVERNAME The SERVERNAME is the name of the target server where 


the Remote IPL machine will be created. The 
SERVERNAME parameter is optional if the Remote IPL 
machines are to be created on the same machine where 
RPLADD is being run. 





Note: Before running the RPLADD utility, you have to make sure that server 


record identifiers, DOS image files and model entries exist on the Remote 
IPL server. 


The results expected from each line in Figure 196 on page 331 are: 


* A Remote IPL definition for OS2_MACH will be created on the local server. 


OS2_MACH will be defined as an OS/2 Remote IPL machine and will be 
created from the R_21_OTK standard configuration files. OS2_MACH will 
boot from drive letter Z: and will be configured for a local SWAPPER.DAT file, 
ISA bus architecture and S-3 Super VGA display. 


* A Remote IPL definition for DOS_MACH will be created on the local server. 


DOS_MACH will be defined as a DOS Remote IPL machine and will be 
created from the R_DTK standard configuration files. DOS MACH will boot 
using the STDSHFUL DOS image file. 


- A Remote IPL definition for NEW_MACH will be created on RIPL_SERV 


server. NEW_MACH will inherit all the configuration information of 
MODEL_MACH. NEW_MACH and MODEL_MACH will exist on the same 
Remote IPL server. 


Enabling Server Records 
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With the GETRPL utility, only server records are enabled that correspond to LAN 
adapter types found at the time the GETRPL command was issued. 


To enable server records that correspond to other LAN adapter types, you have 
to update the RPL.MAP file. 


Besides IBM Token-Ring adapter, Remote IPL officially supports the NDIS LAN 
adapters (as shown in Figure 197 on page 333): 
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Network Driver Interface Specification (NDIS) LAN adapters (ISA or EIS. 


BM Auto LANStreamer ISA Adapter 

BM LAN Adapter for Ethernet 

BM LAN Adapter for Ethernet CX 

BM LAN Adapter for Ethernet TP 

BM PS/2 Adapter for BNC/UTP Ethernet Networks 
- IBM Token-Ring Network 16/4 Adapter 
- 3Com 3C503 Etherlink Adapter 

- 3Com EtherLink 16 (3C507) 

- 3Com EtherLink (3C509) 




















} 
HHHHH 






























































Micro Channel adapters 





- IBM LAN Adapter/A for Ethernet 
- IBM LANStreamer 32MC Adapter 
- 3Com 3C523 Etherlink/MC Adapter 























Figure 197. Supported LAN Adapters for Remote IPL 
Note: The adapters mentioned above are disabled by default. 


Although these adapters are supported, you must enable that support. MPTS 
only delivers the OS2 device drivers. You must manually copy the DOS driver 
.NIF and .DOS and its appropriate .MSG file from the option, device driver or 
diagnostics diskette which come with the LAN adapter to the 

IBMLAN DOSLAN LSP DOS directory. 


The only DOS NDIS driver delivered with OS/2 LAN Server 4.0 is the 
IBMTOK.DOS driver that comes with LAN Support Program 1.36. All other DOS 
NDIS drivers must be manually installed in the appropriate directories from the 
option, device driver or diagnostics diskette. 


Note: Some adapters may not have .MSG files or .NIF files. The .MSG and .NIF 
files, if present, can have a different name than the device driver file. 





Remote IPL support for OS/2 and DOS 


Independent of the operating systems you are using in your Remote IPL 
environment, you always have to set up the DOS and OS/2 Remote IPL 
support. Otherwise, the Remote IPL service cannot be started. 





Example: Enabling RIPL Support for IBM LANStreamer MC32 

Two diskettes, the option diskette as well as the device driver diskette come with 
the adapter. Insert the device driver diskette in drive A:. In the root directory of 
the device driver diskette, you find the files: 

















IBMTRDB.OS2 OS/2 NDIS Device Driver 

IBMTRDB.NIF OS/2 NDIS Network Information File for IBM OS/2 Environmen 
LT6.MSG OS/2 NDIS Message File 

LT6H.MSG OS/2 NDIS Message Help Text 







































































Copy the IBMTRDB.OS2 and IBMTRDB.NIF files into the 

IBMLAN RPL IBMCOM MACS subdirectory of the Remote IPL server. The 
LT6.MSG and LT6H.MSG files must be copied into the IBMLAN RPL IBMCOM 
subdirectory. 
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Note: You may not do that when you want to use the OS/2 drivers that come 
with the Multiprotocol Transport Services product diskette. In some cases 
you may want to upgrade these drivers though. 


In the DOS subdirectory of the device driver diskette, you find the files: 





TIBMTRDB.DOS DOS NDIS Device Driver 
IBMTRDB.NIF DOS NDIS Network Information File for IBM DOS Environments 
LT6 .MSG DOS NDIS Message File 













































































All files mentioned above have to be copied to the Remote IPL subdirectory 
IBMLAN DOSLAN LSP DOS subdirectory. 


In the IBMLAN RPL RPL.MAP file, enable the appropriate server records by 
removing the semicolon in column one. 


Because the IBM LANStreamer MC32 adapter is supported for Remote IPL, all of 
the necessary configuration files to create clients for them are present. 

However, you must enable the server records. You can determine the 
appropriate server records to enable by reading the descriptive comment field 
(field 7) in the server record. 


The entries for OS/2 and DOS with LANStreamer adapter are: 


yyyyyyyyyyyy dosnls.cnf 3 10 N IBMLANS DOS~IBM~LANSTREAMER~MC~32~TOKEN~RING ~ ~ ,,, Z R_DTKLS ~ ~ 














VYVYVYVVYVyy 08221ls.cnf 3 10N~ 0OS2~2.1~IBM~LANSTREAMER~MC~32~TOKEN~RING ~ ~ ,,, ~ R_21_OTKLS ~ ~ 

















Figure 198. Enabling LANStreamer MC32 Support in the RPL.MAP File 


Using the normal Remote IPL requester definition procedure, define the Remote 
IPL requesters using the newly enabled adapter types. 


For Remote IPL OS/2 clients with the LANStreamer MC32 adapter the server 
record identifier is R_21_OTKLS. For Remote IPL DOS clients with the 
LANStreamer MC32 adapter, the server record identifier is R_DTKLS. 


Remote IPL Scenarios 


This section describes typical Remote IPL scenarios in which a LAN 
administrator can be involved. 


Setting Up Remote IPL for ISA/EISA and MCA Machines 


In this example, we will show a possible way to include standard ISA support for 
OS/2 and the IBM Token-Ring Adapter. Speaking of bus architecture, there is 
nothing to consider for DOS Remote IPL clients. 


A workstation record has to be added to the IBMLAN RPL RPL.MAP file so that 
the added record can be used by the RPLADD utility. 


This record will also be used as a pattern for other remote IPL clients by using 
the graphical user interface. 
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Creating an ISA Bus Architecture Workstation Record 
1. Using the GUI of OS/2 LAN Server 4.0, first create a Remote IPL client using 
the default options. See “Create OS/2 Workstation Records for the 
RPL.MAP” on page 317 for more details about the steps to do it. 


These entries are used in this example: 





Machine ID OS2RIPLO1 
Description TSCRIPLWkst01 
Netword adapter address 10005A1D2F04 
Server record identifier R_21 OTK 
Remote IPL boot drive Z 

Title TSCRIPLWkst01 












































This new record in the workstation records section of the 
IBMLAN RPL RPL.MAP file has been added: 


; workstation records 
10005A1D2F04 OS2RIPLO1 ~ FITS\OS2RIPLO1 ANYSRVO1l Z~ ~~ ,,, ~ R_21_OTK ~ ~ ~ 


2. Change the Remote IPL client specific configuration files by issuing the 
RPLSETD command from an OS/2 command line: 





























RPLSETD /C:OS2RIPLO1 /S:S /B:ISA /D:S3SVGA 


See “Remote IPL Configuration Utility RPLSETD” on page 320 for details 
about the parameters used here. While RPLSETD was running, these 
messages were displayed: 





















































OS2RIPLO1 copy of OS2.INI was updated. 
OS2RIPLO1 copy of CONFIG.SYS was updated. 
OS2RIPLO1 copy of CONFIGRI.SYS was updated. 
OS2RIPLO1.FIT was updated. 

OS2RIPLO1 copy of SYSTEM.INI was updated. 
OS2RIPLO1 copy of PROGMAN.INI was updated. 





























Using the RPLADD utility, you may now use the new defined workstation 
OS2RIPLO1 as MODEL NAME for other ISA/EISA machines. 


Using the GUI, you can simply drag the new object while pressing the Ctrl key, 
and drop it into the same folder. You will be prompted to enter a new machine 
ID. Having entered the new machine ID, you will have to modify the network 
adapter address. 


Starting a Medialess Workstation with a Reference Diskette 
1. Perform the procedures described in “Creating a DOS Image from Diskette” 
on page 310 and “Creating a DOS Image from a Definition File” on 
page 311. Insert the reference diskette. If you want to use the MAKEIMG 
utility, invoke: 





MAKEIMG A: RF8556A /SANYSRVO1 /F1.4 











2. Perform the procedure described in “Create DOS Workstation Records for 
the RPL.MAP” on page 315. Use the newly created image file in this 
procedure. 
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Updating Machines with IML Records 


When using the Remote IPL service on any machine that has updatable initial 
microcode load (IML) records, perform the following modification to the remote 
IPL server. (Machines with IML records include Models 8556 and 8557.) 


In this example, it is assumed that you want to update the IML partition of a PS/2 
Model 57. 


1. Copy the $0000000.IML file from the Reference Diskette to the 
IBMLAN DCDB IMAGES subdirectory. 


2. Create a Remote IPL image of the Reference Diskette. See “Creating a DOS 
Image from Diskette” on page 310 for more information. If you want to use 
the MAKEIMG utility, invoke: 


MAK 





Tr 





‘IMG A:$0000000.IML 8556UPD /SANYSRVO1 /F1.4 


3. Edit the IBMLAN RPL OS221xx.CNF file, where xx is either TR for 
token-ring, ET for Ethernet, or PC for PC-Net. 














a. Insert the following new line immediately before the lines starting with 
DRV: 











EXE C: IBMLAN RPL DOS IMLUPDAT.COM 
b. Save the file. 
4. Edit the IBMLAN RPL RPL.MAP file. 


























a. Locate the workstation record for the workstation that requires the 
update. 


b. Update field 14 to specify the name of the Reference Diskette image you 
created at the beginning of this procedure. 


c. Save the file. 


5. Reboot the Remote IPL workstation. 





Working with the Remote IPL Client (OS/2) 


This section describes the Remote IPL client features a remote IPL user can use 
when set up by the LAN administrator. 


Remote IPL Boot Record Change Utility 
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Using the Remote IPL boot record change utility, the Remote IPL user can 
change the access to an operating system that is installed on the remote IPL 
server. 


For example, you have been using the OS/2 system, but you want to Remote IPL 
a reference diskette or run an occasionally used DOS application that does not 
run under DOS on an OS/2 system. You can use this utility to have DOS loaded 
the next time you start your workstation. 


To use this utility, the following prerequisites have to be fulfilled: 


* The Remote IPL client user must be logged on to the domain which contains 
the Remote IPL server. 


- To use different operating systems, specific workstation records have to be 
added to the RPL.MAP file at the Remote IPL server. 
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Use this utility to access a different operating system once. The change will only 
be in effect for the next time the workstation is started. 


* Select OS/2 to use the OS/2 system the next time this workstation is started. 


* Select DOS to use the DOS system the next time this workstation is started. 


If you selected OS/2, the selection list contains the FITs that are available for this 
workstation. If you select DOS, the list contains the DOS images that are 
available for this workstation. 


To make an alternate boot selection, select the desired operating system, then 
select the new OS/2 FIT or DOS image and select Change. The window displays 
the name of the server that will handle the Remote IPL request the next time you 
start the workstation. 











—I 


OSi2 System LAN Services Network UPM Services  Nebwark Applications 


7] 


Remote IPL System 
Change Utility 


















Remote IPL System Change Utility 


Minimized i 
Window Viewer | 


Select a configuration for when you next restart your 
computer. 


Select an Operating OS/2 FITs Available: 
System. to Use: 
By OSle 


YW BOS 


Remote IPL Server: 


2 ANYSRV81 


Drive A 


Shredder 








Figure 199. Remote IPL Boot Record Change Utility window 


Installing the Change Boot Record Utility CHGBOOT 

The Remote IPL Boot Record Change Utility is available as an applet and 
sharable as an network application. To make it available on the Remote IPL 
server, use the following steps: 


1. Insert the first Productivity Aids diskette of OS/2 LAN Server 4.0 into drive A: 
2. Issue the A: INSTALL command from an OS/2 command line. 


3. At the LAN Services Productivity Aids Installation window select 
CHGBOOT.ZIP, then Install. 


These files will be copied to the IBMLAN PRODAIDS directory. 
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CHGBOOT . EXE 
CHGBOOT .HLP 
CHGBOOT . DOC 

















4. Copy the extracted files as follows: 











IBMLAN PRODAIDS CHGBOOT.EXE ==> IBMLAN RPL IBMLAN NETPROG 
\IBMLAN\PRODAIDS\CHGBOOT.HLP ==> \IBMLAN\RPL\IBMLAN\HELP 





















































so that these files are accessible at the Remote IPL client. 


5. If desired, create a public OS/2 application, and assign it to the remote IPL 






































users. 

Application Name CHGBOOT 

Description Change Boot Record Utility 
Command CHGBOOT . EXE 

Program Location On requester 

Drive Z 

Remaining path to program \IBMLAN\NETPROG 

Program Mode OS/2 PM 

Title Change Boot Record Utility 





RPLLSOBJ Utility 
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This procedure will recreate the LAN Services, LAN Server Books, and UPM 
folders on a Remote IPL client Desktop. The utility must be issued from an OS/2 
command line at the Remote IPL client. 


Syntax of this command is: 











--RPLLSOBJ- ---- - - - - ----- - - - 
LS- -UPM- 
-LSB- 

Parameter Description 

LS Indicates that the LAN Services and LAN Server Books folders and 
objects should be recreated. 

LSB Indicates that the LAN Server Books folder and objects should be 
recreated. 

UPM Indicates that the UPM folder and objects should be recreated. The 
Logon and Logoff objects will be shadowed to the LAN Services 
folder. 


No parameters defaults to LS, LSB, and UPM. You may add this utility as a 
network application to Remote IPL users. An icon is delivered with the utility. 





Warning 


Do not issue this command at the server. If you do so, you will lose your 
LAN administration specific objects. 
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This chapter describes the Remote Initial Program Load (called R/PL or Remote 
IPL) enablement of DB2 CAE for OS/2 V2.1 with OS/2 LAN Server 4.0. Prior to 
enabling DB2 CAE for OS/2 V2.1 for remote IPL the remote IPL feature of OS/2 
LAN Server 4.0 must be installed as described in Chapter 13, “Remote IPL” on 
page 285. 


In our environment, we installed the DB2 Server on the same machine on which 
LAN Server was installed. We installed DB2 CAE for OS/2 V2.1 on another OS/2 
machine and copied the required SQLLIB files to the LAN Server's RIPL tree. In 
our case, DB2 Server uses the primary LAN adapter (0), whereas LAN Server 
uses the alternate LAN adapter (1). To run both products you need to verify that 
there are enough NetBIOS resources available for both LAN Server and DB2 
Server. 


To avoid any confusion, DB2 Server does not have to run on a LAN Server 
machine. From a performance point of view we recommend DB2 Server and 
LAN Server not be installed on the same PC. 
Following is the description of our test environment: 
LAN Server 4.0 Advanced is installed on OS/2 Warp V3 with WIN-OS/2. 
- Domain name: ANYDOMO01; Server name: ANYSRVO1 
DB2 Server is installed on the C: SQLLIB. 
DB2 Server workstation name (nname) is ITSCDB22. 
SAMPLE database has been created on the DB2 Server. 


DB2COMM environment variable must be set correctly for DB2 Server to 
support NetBIOS protocol. 


UPM user IDs for the CAE clients have been created on the DB2 Server. 
RIPL client name is DB2RPLO1. 


DB2 CAE client code is installed on the LAN requester machine and the code 
is copied to the LAN Server's RIPL tree. 


Actually the DB2 Server could be any supported server by the DB2 CAE for OS/2 
V2.1. The supported servers are: 


DB2 Server for OS/2 

DB2 Server for AIX/6000 

DDCS/2 gateway to connect to a DRDA server 
DDCS/6000 gateway to connect to a DRDA server 


We used NetBIOS protocol for DB2 CAE client to access the DB2 Server. If you 
want to use either APPC, TCP/IP or IPX/SPX you need to configure the remote 
IPL machine to have CM/2, TCP/IP or NetWare requester. 
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Installing and Configuring DB2 Server for OS/2 


Note 





You can skip this section and go directly to the “Setting Up Remote IPL CAE 
Workstations on the Server” on page 343 if you have already installed the 
DB2 Server and have some databases prepared. This section is intended for 
the people who have never installed the DB2 Server. 





To install DB2 Server for OS/2 you need to issue the INSTALL command from an 
OS/2 command line from either the diskette drive or the CD-ROM drive. Select 
the components you want to install. 


After all files have been transferred to the hard disk you need to reboot the 


machine to activate the changes. Then you need to configure the database 
server. 


Configuring NetBIOS for DB2 Server 
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Since NetBIOS is the common protocol for remote IPL machines you better use 


NetBIOS as a supported protocol at your DB2 Server. Prerequisites for enabling 
NetBIOS support on the DB2 Server are: 


Multiprotocol Transport Services (MPTS) must be installed and configured 
with the NetBIOS protocol support. This is a default for RIPL machines. 

* The database manager must be configured for NetBIOS support. The 
database manager configuration file must be updated with the workstation 
name (nname). 

* The DB2COMM environment variable must be set correctly to support 
NetBIOS protocol. 

+ The database manager must be started. 


To configure the database manager of your DB2 Server to support NetBIOS, 
open the IBM DATABASE 2 folder from the OS/2 Desktop. Then continue as 
follows: 


1. Open the Database Director. 


2. Using mouse button 2, click on the DB2 object of the database manager 
object. 


3. Click on the Configure... menu choice as shown in Figure 200 on page 341. 
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Figure 200. Configure Choice at the Database Director Window 


4. At the Database Director settings notebook, as shown in Figure 201, select 
the Protocols page. 
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Default accounting string 





dft_account_str 
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Apply 
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Figure 201. Database Director Configuration Settings Notebook 
5. In the Workstation name field type the DB2 Server name. In our example, 
we typed in ITSCDB22. 
6. Select OK to save the entry. 


7. An information window will inform you to stop and restart the database 
manager. Before you do so, edit the CONFIG.SYS file with an ASCII editor 
and change the DB2COMM statement to: 

















SET DB2COMM=NETBIOS 
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Then reboot the system. 





8. Issue the DB2START command from an OS/2 command line to start the 
database manager. 








Note: If you experience failures in starting NetBIOS protocol support please 
check the DB2DIAG.LOG file which resides in the SQLLIB DB2 directory. In 
most cases a lack of NetBIOS resources causes the DB2 Server not to start 
NetBIOS protocol support. 


Creating a SAMPLE Database 
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After the first reboot of your server workstation, the Using DB2 for the first time 
window will be opened for you as shown in Figure 202. 


Ye GR GG re ear Onis Sear HOG Gren e gmc n eg seman ene Grane gion eG: 





Welcome to DB2! 


To get started you need: 


4 user ID | Set up user IDs to access DB2 ... 








and 





4 database, 
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Figure 202. Using DB2 for the first time Window 


You will be prompted to locally logon to the workstation. This type of logon has 
nothing to do with logging on to a LAN Server. DB2/2 uses the local logon type 
whereas LAN Server uses the domain logon type. If you have a configuration 
where DB2 Server is installed on the same machine as LAN Server, your local 
user ID and password are the same as the one that is used with LAN Server. In 
all other cases the local user ID is USERID along with the password of 
PASSWORD. You may want to change that before you actually create the 
SAMPLE database: 


1. Perform a local logon to the workstation using the user ID USERID with the 
password PASSWORD. From the OS/2 command line, the command is: 


LOGON USERID /P:PASSWORD /L 




















Note: If you are logged on to a LAN Server please logoff from LAN Server. 
By issuing the LOGOFF /L command you can select the destination you want 
to logoff from. 


2. Open the UPM Services folder and start User Account Management. The 
command from an OS/2 command line would be: 


UPMACCTS 
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3. From the action bar pull down, select the Manage menu. Then select 
Manage Users ... to create user IDs for DB2 access. 


Once you have decided which user ID to use and logged on locally, you may 
push the Create the sample database ... button to create the sample database. 


Setting Up Remote IPL CAE Workstations on the Server 


The file index tables (FIT) provides the mapping function to the OS/2 remote IPL 
clients when accessing the files/directories. By default the RIPL client will have 
a boot drive as the Z: drive and FIT table provides a flexible mapping for any 
directories and/or files under the Z: drive. With this technique we can set up the 
CAE RIPL client's read-only files pointing to the shared SQLLIB images and 
read-write files pointing to the client unique area. 


Because the CAE client code must be copied to the remote IPL server's 
read-only area, you should first install DB2 CAE for OS/2 on any LAN Requester 
machine and copy all the code to the server. If DB2 Server is not installed on 
the LAN Server machine, you can install the DB2 CAE for OS/2 on the server. 
This is because, after the first DB2 family product for OS/2 is installed, all other 
DB2 family products for OS/2 must be installed on the same path. The existing 
path is shown on the screen but greyed out, and you cannot change the path. 


As we want to keep the DB2 CAE for OS/2 code in a separate path from where 
DB2 Server code is installed, we cannot install the DB2 CAE code on the same 
server PC. 


If you generally want to use DB2 CAE for OS/2 on all remote IPL clients, you 
must update the default FIT tables that come with the OS/2 LAN Server 4.0 
product. The default FIT table for OS/2 Warp is DEFALT30.FIT under 
\IBMLAN\RPLIFITS. If a limited number of remote IPL clients are supposed to 
use DB2 CAE for OS/2, you might want to take one RIPL client, and make 
modifications. Then use it as a template for other DB2 CAE remote IPL 
workstations. Creating a RIPL workstation definition based on the existing client 
definition is simply done by selecting Create another of the object. 


In our example the default FIT table DEFALTS30 is used, so all of RIPL clients will 
have the DB2 CAE function enabled. Since our server name is ANYSRVO1 and 
your server name is different, you need to change all of the references of 
ANYSRVO01 to your actual server name. 


Assuming the Z: drive is the Remote IPL client's startup drive (which is the 
default), perform the following steps to enable DB2 CAE for OS/2 for remote IPL 
clients: 


1. Install the DB2 Client Application Enabler (CAE) for OS/2 program on any 
LAN requester workstation by issuing the INSTALL command either from 
diskette or from a redirected drive. 


2. Log on with an administrator's user ID to the LAN Server domain. 


3. Assign the server's RIPL tree directory to your workstation as a redirected 
drive by issuing the following command: 














NET USE X: ANYSRVO1 C$ 


This command gives you the RIPL server's C: drive as the redirected X: drive 
at the DB2 CAE for OS/2 workstation. 
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4. Create a SQLLIB subdirectory in the IBMLAN RPL directory on the RIPL 




















server: 


X: 
MD \IBMLAN\RPL\SQLLIB 





























Remember this SQLLIB should contain all the code of the CAE client. 
5. Copy all files of the CAE product from the CAE workstation to the RIPL tree 


of the server: 





XCOPY C: SQLLIB X: IBMLAN RPL SQLLIB /S /] 














CG] 


This command should be executed on the CAE client machine. 
6. Copy FFST/2 related files since they are required by DB2 CAE for OS/2: 








COPY C: OS2 DLL EPWPSI32.DLL X: IBMLAN RPL 0S2.30 OS2 DLL 
































COPY C:\0S2\DLL\EPWSVC32.DLL X:\IBMLAN\RPL\OS2.30\0S2\DLL 














7. Edit the appropriate FIT file at the server. In this example, it is the OS/2 Warp 
V3.0 FIT file named DEFALT30.FIT. There are three default FIT files for each 


OS/2 version: 









































BMLAN RPL FITS DEFALT20.FIT <--- for OS/2 Version 2.0 
\IBMLAN\RPL\FITS\DEFALT21.FIT <--- for OS/2 Version 2.1 
\IBMLAN\RPL\FITS\DEFALT30.FIT <--- for OS/2 Version 3.0 





























First, delete the Database Manager/SQLLIB section and then add a DB2 CAE 


for OS/2 V2.1 section such as the following lines: 

















; All DB2 CAE for OS/2 V2.1 files for read-only and shared 





Z:\SQLLIB SQLLIB 


























; Per-workstation writeable DB2 directories/files. 























1ES \DEFALT30\SQLLIB\DB2 



















































































Z:\SQLLIB\DB2 \\ANYSRV01\WRKF 
Z:\SQLLIB\DB2CLI.IN \\ANYSRV01\WRKF 
Z:\SQLLIB\DB2IDIR \\ANYSRV01\WRKFIL 


























1ES\DEFALT30\SQLLIB\DB2CL 






































8. At the server, create a SQLLIB subdirectory in the 











directory, for example: 








MD C: IBMLAN RPLUSER DEFALT30 SQLLIB 






































MD C: \IBMLAN\RPLUSER\DEFALT30\SQLLIB\D 
































9. Perform the following copy operations at the server: 


ES\DEFALT30\SQLLIB\DB2IDIR 











BM 














AN RPLUSER DEFALTXx 














B2 











XCOPY C: IBMLAN RPL SQLLIB DB2 C: IBMLAN RP 

















USER DEFALT30 SQLLIB DB2 



































COPY ee \ IBM iAN\RP i\SQ ili B\DB2C J N 








Gey 





BMLAN \RPLUSER\DEFALT30\SQ 












































COPY C:\IBMLAN\RPL\SQLLIB\DB2IDIR C: 











\ 








BMLAN \RPLUSER\DEFALT30\SQLL 





/S 


LL: 


























B\’ 





10. Set up the access control of the new subdirectories for remote IPL. At the 


server, issue the following commands: 








NET ACCESS C: IBMLAN RPL SQLLIB /ADD RPLGROUP:RX 
NET ACCESS C:\IBMLAN\RPL\SQLLIB /APPLY 















































NET ACCESS C:\IBMLAN\RPLUSER\DEFALT30\SQLL 
NET ACCESS C:\IBMLAN\RPLUSER\DEFALT30\SQLL 
























































B /ADD RPLGROUP: RWCXDAP 





























B /APPLY 





Note: You need to logon with the administrator ID to issue the NET ACCESS 


command. 


11. Edit CONFIG.SYS templates. For OS/2 Warp, edit the following CONFIG.DEF 


file: 











PM BMLAN RPL MACHINES DEFALT30 CONF 


























G.] 











Change THREADS=256 to THREADS=1024. 
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+ Add Z: SQLLIB DLL to the LIBPATH statement. 

- Add Z: SQLLIB BIN to the SET PATH statement. 

* Add Z: SQLLIB HELP to the SET HELP statement. 

* Add Z: SQLLIB BOOK to the SET BOOKSHELF statement. 





- Add the following statements as last lines: 





SET DB2CHKPTR=ON 
SET DB2INSTANCE=DB2 
SET DB2PATH=Z: \SQLLIB 
























































12. Create your Remote IPL clients from the graphical user interface of LAN 
Services. For example, create a remote IPL client named DB2RPLO1 by 
dragging and dropping the Remote IPL Requester Template to the open 
space within the folder. 


The following screen example shows the operation of selecting and dragging 
of the Remote IPL Requester Template on to the free space within the folder. 
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Figure 203. Dragging of Icon to Create a RIPL Client 


With this operation LAN Server will automatically create all the files and 
directory trees required for the new RIPL client. LAN Server will create the 
following client unique files: 


* New FIT file for a client. All the lines which point DEFALT30 will be 
replaced with the new client name. 








* A new subdirectory with the client name under IBMLAN RPLUSER and 
xcopy all the files from the IBMLAN RPLUSER DEFALT30. 



































* Access control for the new directory trees, so a new RIPL client can 
create/write/delete any files in these directory. 


* Client unique CONFIG.SYS file under the following directory: 








BMLAN RPL MACHINES Client_Name 
For example, CONFIG.SYS for DB2RPLO1 client will be: 
BMLAN RPL MACHINES DB2RPLO1 CONFIG.SYS 












































Check if a new RIPL client ID is a member of RPLGROUP group by using the 
following command: 





NET GROUP RPLGROUP 





If you don't see the newly added RIPL client name, you must add it: 
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NET GROUP RPLGROUP new_client_name /ADD 





This might happen if the LAN Server code has some defects. 


If you need to set an implicit database or default database for connection, add 
the following line to the CONFIG.SYS file: 


SET DB2DBDFT=SAMPLE 
































You can use the actual database alias name by replacing SAMPLE. You cannot do 
this update at the client side because you only have a read only access. The 
users at the client need to ask the LAN Server administrator to update their 
CONFIG.SYS. 


The RIPL client can view the PROTOCOL.INI file but the file cannot be updated 
by the client. The PROTOCOL.INI file is located on the server under the 
following directory: 





























IBMLAN RPL MACHINES Client_Name PROTOCOL.IN 


LANTRAN.LOG can be located in the following directory: 
BMLAN RPLUSER Client_Name IBMCOM LANTRAN. LOG 





























IBMLAN.INI can be located in the following directory: 



































BMLAN RPLUSER Client_Name IBMLAN IBMLAN.IN 











AUTOEXEC.BAT for DOS and WINOS2 can be located in the following directory: 
BMLAN RPLUSER Client_Name AUTOEXEC. BAT 
































If you want to use the SYSLOG function from the CAE RIPL client, you need extra 
setup steps. This is because SYSLOG wants to have a read/write access to 

OS2 SYSTEM subdirectory. To enable the SYSLOG function, perform the 
following steps: 


1. Add the following line into the FIT file: 


; For SYSLOG function 
Z:\OS2\SYSTEM \\ANYSRV01\WRKFILES \DEFALT3 0\0S2\SYSTEM 


























2. Xcopy the required files with the following command: 











G 


XCOPY C:\0S2\SYSTEM C:\IBMLAN\RPLUSER\DEFALT30\0S2\SYSTEM /S /1 
3. Add the following statements into the client's CONFIG.SYS file. 


























DEVICE=Z:\0S2\LOG.SYS 
RUN=Z: \OS2\SYSTEM\LOGDAEM . EXE 






































Setup at CAE Remote IPL Client Machine 


1. Boot your remote IPL client. When the boot process has been finished, open 
an OS/2 command line. 


2. Change to the SQLLIB MISC subdirectory and create an IBM DATABASE 2 
folder on the Workplace Shell Desktop. For example: 





CD SQLLIB MISC 
DB2ICO 





























3. You need to configure your remote IPL DB2 client by opening the Client 
Setup object which resides in the IBM DATABASE 2 folder. 


a. Catalog NetBIOS node to access the DB2/2 server. 
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b. Catalog database name (create alias name) to be accessed. 
c. Connect to the database. 


Those client unique information will be stored in the following files: 











Z: SQLLIB DB2 SQLNODIR SQLNODIR <--- Node directory 
Z:\SQLLIB\DB2\SQLDBDIR\SQLDBDIR <--- Database directory 













































































. You might want to set up your local user IDs now. However this is optional 
step and not required for accessing DB2 Server. The default user ID is 
USERID with the password PASSWORD which you must use for first time 
local logon: 





LOGON USERID /P:PASSWORD /L 

















a. Open the UPM Services folder and start User Account Management. 


b. From the action bar pull down, select the Manage menu. Then select 
Manage Users ... to create the user IDs you need to have for DB2 access. 
For example, we created the sample database from user ID A948R4, so 
we must use the same user ID at node logon time. If we have the user ID 
A948R4 defined locally at RIPL workstation, we will have no prompt when 
connecting to the database. 


Note: The user ID along with the password will be stored on the remote 
IPL server when you are creating the local user IDs. The local user IDs 
will be stored in the following location on the server: 





C: IBMLAN RPLUSER ripl_client_name IBMLAN ACCOUNTS NET.ACC 

















DB2 uses the node logon and it uses a local UPM user account database 
NET.ACC in the DB2 server machine. If you attempt to connect to a database 
but you haven't logged on locally, DB2 CAE will prompt you to perform a 

node logon. If you already logged on locally with the same user ID and 
password, you will have no prompt and DB2 will automatically authenticate 
your ID at the DB2 server. This has nothing to do with the LAN Server 
domain logon. 


Figure 204 shows all three logons are active at same time on the remote IPL 
client. 


Logott 


Select a session to log off: 


User ID Type Session Remote Name 


LAN Server 21 ANYDOMO 1 
Local 21 













~ 





Figure 204. Example of All Three Logons 


The fact is that you neither need to logon to the LAN Server nor logon locally 
when you access the DB2 server. You only need a node logon when you 
connect to the database. RIPLed workstation has a session with the LAN 
Server but there is no logon required to complete the remote IPL. 
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Chapter 15. Remote IPL of DB2 CAE for Windows V2.1 


This chapter describes the Remote Initial Program Load (called R/PL or Remote 
IPL) enablement of IBM DB2 CAE (Client Application Enabler) for Windows V2.1. 
Prior to enabling Windows for remote IPL at least the DOS remote IPL feature of 
OS/2 LAN Server 4.0 must be installed as described in Chapter 13, “Remote 

IPL” on page 285. Following is the description of the test environment we used: 


LAN Server 4.0 Advanced installed on OS/2 Warp V3 with WIN-OS/2: 
- Domain name ; ANYDOMO1; Server name ; ANYSRVO1 


- File alias FILESET pointing to the D: FILESET directory on the server is 
assigned as W: drive for remote IPL user group. 


- User home directory is defined for each remote IPL user, for example: 





D: LANUSER RPLUSERI1 














Home directory is assigned to each user as the H: drive. 


- DB2 CAE for Windows was installed on the server's WIN-OS/2 session. 
We also installed DB2 CAE for Windows on the real Windows 3.1 PC 
running DLS and copied all the files to the server's D: FILESET and it is the 
same result. 




















DOS workstations for the reference: 
- PC DOS 6.3 

- DOS LAN Services 

- Windows 3.1 

- DB2 CAE for Windows V2.1 





Setup Windows 3.1 Remote IPL 


Remote IPL users cannot use a WIN-OS/2 environment from a server. Therefore 
Windows 3.1 must be installed on the server separately to allow remote IPL 
users to load Windows on their remote IPL workstations. The Windows remote 
IPL environment can be set up with the following methods. 





Attention 


You must have a sufficient number of Windows licenses to use Windows as a 
shared application from the server. 





Sharing Windows Directory as Redirected Drive 


© Copyright IBM Corp. 1995 


To share Windows as a fileset takes advantage of having the major files 
available on a network drive whereas the user specific files, such as system 
setting files, INI and GRP files, are stored on a personal directory, which can be 
either a local drive or meaningfully a user home directory on a server. Also the 
Windows environment can be set up individually, for example graphics adapter 
and printer driver. 


You can install a shared copy of Windows on a server remotely from a LAN 
attached workstation or locally. 
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Windows Installation and RIPL Setup at Server 
1. Insert the first Windows diskette in drive A: on the server. 


2. Open a DOS Full Screen command prompt and issue the following command: 
A: SETUP /A 





This will start a program under the WIN-OS/2 session. The administrative 

setup of Windows will be loaded and will prompt you to type in the 

User/Group name and Company name. Then you need to specify the drive 

and directory on which all files will be installed. This procedure also marks 

all files read-only. For example we used the path name D: FILESET WINDOWS. 


























3. Open the LAN Server Administration GUI and define the group name for DOS 
DB2 RIPL clients, for example RPLUSERS or DOSDB2RP. This group name 
can be any name. 


4. Define the drive and directory you have chosen in the step before as a 
directory resource and assign the drive to the group to which remote IPL 
users belong. For example: 


a. In the Resource Definitions folder of LAN Server administration GUI, drag 
and drop a Directory template. You must fill in the required fields which 
are alias, server name and path. The following are the example of our 
test case: 





Alias FILESET 

Description Shared Fileset Directory 
Server name ANYSRVO1 

Path D:\FILESET 









































After you define the alias, the system will prompt you to create an 
access control list. From the GUI, apply read and execute (RX) 
permissions to the group RPLUSERS that will contain the DOS DB2 CAE 
remote IPL users. The system will automatically create an access 
control profile. 


b. From the Resource Definitions folder drag the FILESET directory alias 
and drop the object onto the group icon of RPLUSERS. Specify a local 
drive letter (for example W:) to be assigned. 


Note: Do not use the RPLGROUP because this group only contains 
remote IPL machine names. You should define a group, for example 
RPLUSERS, to which all DOS DB2 remote IPL logon users belong. 


Unlike the OS/2 remote IPL, you must logon at the RIPL client machine 
while remote IPL is in progress. The RIPL client will have a redirected 
drive W: ,for example, to start Windows. Because of this, the user IDs for 
DOS Windows remote IPL must be assigned to a particular group name. 


5. Specify a user home directory for each DOS DB2 user ID. You don't need to 
do this if the remote IPL client has a local drive on which the user can store 
the additional files. 


6. You may need to modify the UMB_CFG.SYS, STD_AUT.BAT and RIPL.BAT 
files which reside in the C: IBMLAN DOSLAN NET directory at the remote 
IPL server. 


a. UMB_CFG.SYS file: Add the COUNTRY.SYS device driver if you need 
national language support. 


b. STD_AUT.BAT file: Add keyboard support for national language support 
and mouse support if necessary. 
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c. RIPL.BAT file: Add W: WINDOWS to the PATH statement. Also add 
H: WINDOWS to the PATH statement, where H: is the home directory 
drive letter. If you like, add the WIN command as the last line. 





Find examples in “Create DOS IPL Images” on page 307. 
-—— Enhanced Mode Consideration 


If remote IPL users need to run Windows in enhanced mode with Upper 
Memory Block (UMB) support, modify the following CONFIG.SYS 
statement in the IBMLAN\DOSLAN\NET\UMB_CFG.SYS file as follows: 


DEVICE=A: \EMM386.EXE NOEMS /Y=Z:\DOSLAN\DOS\EMM3 86 .EXE 

































































You can hold the following two steps after your modification for remote IPL of 
CAE for Windows, unless you want Windows RIPL now. 


7. Create a DOS image from a definition file if not done already, as described in 
“Creating a DOS Image from Diskette” on page 310. To load Windows in 
enhanced mode you need to select STDSHUMB. 


8. Create the DOS remote IPL clients from the LAN Server Administration GUI 
of LAN Services. (See “Create Workstation Records for the RPL.MAP File” 
on page 314 for more information) 


DOS RIPL users can have their local hard disks as C: drive or so on. Note that 
RIPL users cannot modify their AUTOEXEC.BAT, CONFIG.SYS and so on, 
because these files are packed into a DOS image file on the server. When you 
need to modify these DOS files, you must modify the original files such as 
STD_AUT.BAT and recreate the RIPL client. 


Setup at DOS DB2 Remote IPL Client 
After the preparation steps at the server have been finished, perform the 
following steps at the remote IPL client: 


1. Logon to the server with the user ID that belongs to the remote IPL users' 
group, for example RPLUSERS group. This will give you the W: drive when 
you logon. This logon user ID has nothing to do with the DB2 server. 


2. Change to the W: drive. 


3. Issue the following command: 





W: WINDOWS SETUP /N 











The /N option lets you set up the shared copy of Windows. You will have to 
specify a drive and directory on which the user specific files will be copied 
to. Specify either a local drive or an assigned user home directory, such as 
H: WINDOWS. 


As shown in Figure 205 on page 352, the following files will be copied to the 
personal directory. 
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SYSTEM INI 1,539 08-29-95 4:00p 
WIN INI 3,460 08-29-95 4:00p 

WIN COM 44,170 08-29-95 4:00p 

BOOTLOG TXT 1,187 08-29-95 4:00p 
MOUSE INI 24 08-29-95 4:00p 

CONTROL INI 3,680 08-29-95 4:00p 
EMM3 86 EXE 110,174 12-31-93 3:1lla 
SMARTDRV EXE 43,609 12-31-93 3:1lla 
HIMEM SYS 13,824 12-31-93 3:1lla 
RAMDRIVE SYS 5,873 12-31-93 3:1lla 
WINVER EXE 3,904 12-31-93 3:1lla 
_DEFAULT PIF 545 08-29-95 4:00p 
DOSPRMPT PIF 545 08-29-95 4:00p 
PROGMAN INI 206 08-29-95 6:20p 
REG DAT 2,556 08-29-95 4:00p 

MAIN GRP 9,918 08-29-95 6:20p 
ACCESSOR GRP 16,103 08-29-95 6:20p 
GAMES GRP 2,504 08-29-95 6:20p 
STARTUP GRP 44 08-29-95 6:20p 





Figure 205. User Specific Windows 3.1 Files Stored in the Personal Directory 
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DB2 CAE for Windows will be made available as a shared application. The code 
itself will be installed just once on the server. User specific files should be 
copied to each user's home directory. Each remote IPL logon user has control 
over its own configuration files. 


When setting up DB2 CAE for Windows pay attention to the following steps: 


Setting Up DB2 CAE for Windows on the Server Machine 
1. Start a windowed or full screen WIN-OS/2 session on the RIPL server 
machine. 


2. Insert the first diskette of DB2 CAE for Windows in drive A:. At the File 
pull-down menu select Run .... Type in the following command: 


INSTALL 
Or you may open the file manager and select INSTALL.EXE on A: drive. 


3. At the pop-up window where you have to type the drive and directory, type: 





D: FILESET SQLLIB 




















When the installation has finished, proceed with the next steps. 


4. Copy the following files from the C: OS2 MDOS WINOS2 SYSTEM directory 
to the D: FILESET WINDOWS directory: 


DB2CLIW. DLL 
DB2ODBC.DLL 


5. In order to enable the ODBC interface, perform the following steps: 






































a. Copy the following ODBC driver manager files from the 
D: FILESET SQLLIB WIN BIN directory to the D: FILESET WINDOWS 


directory: 





ODBC .DLL 
ODBCINST. DLL 
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b. If the ODBC Installer is executed on the WIN-OS/2 session, you may have 
the following files to copy. 








COPY C: OS2 MDOS WINOS2 ODBC.INI D:FILESET WINDOWS 
COPY C:\O0S2\MDOS\WINOS2\ODBCINST.INI D:FILESET\WINDOWS 






















































































These files will be finally copied to the appropriate directory in step 9. 


c. Execute ODBC Installer by double-clicking its icon. However, V2.1 has a 
problem with the ODBC Installer. Since the ODBC Installer opens the 
Windows directory with read/write mode, for example 
D: FILESET WINDOWS, it will fail with the error message. We suggest to 
manually edit the ODBCINST.INI file to get the same result, instead of 
executing the ODBC Installer. The following should be the contents of 
the ODBCINST.INI file in the D: FILESET WINDOWS directory: 


[IBM DB2 ODBC DRIVER] 
Driver=W: \WINDOWS\DB2CLIW. DLL 
Driver=W: \WINDOWS\DB2O0DBC. DLL 






















































































[ODBC Drivers] 
TBM DB2 ODBC DRIVER=Installed 


6. Copy the following file from the C: OS2 MDOS WINOS2 directory to the 
D: FILESET WINDOWS directory: 
IBMDATAB.GRP 
This file will give the remote IPL user the IBM DATABASE 2 group folder 


which is shown in Figure 206. You will customize this group folder later in 
the “DB2 CAE for Windows Remote IPL Client Setup” on page 354. 
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Figure 206. IBM DATABASE 2 Windows Group 


7. Create the following subdirectories in each user's home directory. Assuming 
RPLUSER1 is a valid user ID with an assigned home directory under the path 
of D: LANUSER, the commands will be, for example: 











MD D: LANUSER RPLUSER1 SQLLIB 























8. Perform the following operation to extract the required INI files. 





COPY C: OS2 MDOS WINOS2 DB2.INI D:FILESET WINDOWS 
COPY C:\O0S2\MDOS\WINOS2\DB2CLSW.INI D:FILESET\WINDOWS 
COPY C:\O0S2\MDOS\WINOS2\DB2CLI.INI D:FILESET\WINDOWS 


9. Edit the D: FILESET WINDOWS DB2.INI file and make the following 
modifications: 
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[DB2 Client Application Enabler] 
DB2 INSTANCE=DB2 

DB2INSTPROF=H: \SQLLIB 
DB2 PATH=W: \SQLLIB\WIN 
























































10. Issue the following COPY commands: 
















































































































































































COPY D: FILESET WINDOWS DB2.INI D: LANUSER RPLUSER1 WINDOWS 

COPY D:\FILESET\WINDOWS\DB2CLSW.INI D: \LANUSER\RPLUSER1\WINDOWS 
COPY D:\FILESET\WINDOWS\DB2CLI.INI D: \LANUSER\RPLUSER1 \WINDOWS 
COPY D:\FILESET\SQLLIB\DB2IDIR D: \LANUSER\RPLUSER1\SQLLIB 

XCOPY D:\FILESET\SQLLIB\DB2 D:\LANUSER\RPLUSER1\SQLLIB\DB2 /S /E 






























































11. Edit the C: IBMLAN DOSLAN NET STD_AUT.BAT file using an ASCII editor, 
such as EPM, and add the following lines at the beginning of the file: 








SET HELP=W: SQLLIB WIN HELP 
SET IPF_PATH=W: \SQLLIB\WIN 
SET BOOKSHELF=W: \SQLLIB\BOOK 


12. Edit the C: IBMLAN DOSLAN NET RIPL.BAT file using an ASCII editor, such 
as EPM, and extend the PATH statement to: 


W: SQLLIB WIN BIN;H: SQLLIB; 
Your RIPL.BAT file could look like Figure 207. 

















































































































set path=%1:\DOSLAN\NET; %1:\DOSLAN\DOS;W: \WINDOWS; H: \WINDOWS;W: \SQLLIB\WIN\BIN; H: \SQLLIB 
set comspec=%1: \DOSLAN\DOS\COMMAND . COM 
set TEMP=H: \WINDOWS 








S1: 


CD DOSLAN\NET 





fF not $2 == RW GOTO DISKBOOT 
1:\DOSLAN\NET\RPLTERM 
: DISKBOOT 


B- 








oe 











NET LOGON * 
CD \ 


WIN 











Figure 207. RIPL.BAT (Modified for Windows and DB2 CAE for Windows Support) 


13. Create (or recreate) the DOS image file, for example STD3HUMB, to make 
the changes to the remote IPL client's AUTOEXEC.BAT file active. 


14. Create (or recreate) the DOS remote IPL clients from the Administration GUI 
of LAN Services. (See “Create Workstation Records for the RPL.MAP File” on 
page 314 for more information) 


DB2 CAE for Windows Remote IPL Client Setup 
The following are the final setup at the remote IPL workstation: 


1. Start a remote IPL workstation that should use DB2 CAE for Windows. 


2. Logon to the domain with a valid user ID that was set up for a remote IPL 
user. This gives you the server's fileset directory assigned as drive W:. If 
Windows or the NETGUI of DOS LAN Services was loaded automatically, exit 
the application. This gives you a DOS command prompt. 


3. Copy the W: WINDOWS IBMDATAB.GRP to the H: WINDOWS directory. 
4. Edit the Hi: WINDOWS PROGMAN.INI file and add the following line: 
Group5=H: WINDOWS IBMDATAB.GRP 
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The file name of the GRP file is dynamically generated by the Windows and it 
may not be the same as IBMDATAB.GRP. You can replace this name with 
your own environment. 


. Start Windows by issuing the WIN command. 





. Note that this step only has to be done once: All path statements of all icons 
which reside in the IBM DATABASE 2 group folder must be modified. Select 
icon by icon and press Alt-Enter to modify the program item properties. 
Instead of the path of D: FILESET SQLLIB you must type: W: SQLLIB. While 
changing the path, you also need to select Change Icon ... to retrieve the 
program icon. Find an example of how to modify the Logon properties from 
the picture shown in Figure 208 to the picture shown in Figure 209. 

































Command Line: B:\FILESET\SGLLIBYWIN\BIN\B 7 YT, 
= aE LLL 
Working Director: B:\FILESET\SGLLIB\WIN|BIN 
shortcut Key: None 


[| Bun Minimized _Ohe LE 













































Description: 


Shartcut Key: 


Command Line: 


Working Directory: WASGLLIBYWIN\BIN 


Lagon 








WOASOLLIB\WIN\BIN\DB2LOGO 











None 

















| Bun Minimized 








ws 











Figure 209. Properties of the Logon Program Item (Changed) 


Copy the modified IBMDATAB.GRP file back to the server: 
COPY H: WINDOWS IBMDATAB.GRP W: WINDOWS 























This allows all of DB2 CAE RIPL users don't need to modify the 
IBMDATAB.GRP file. If the logged on user ID does not have an administrator 
authority, this COPY command will fail. Under our assumption that 

W: WINDOWS is read only to RIPL users, this is normal. In this case you 
need to copy the H: WINDOWS IBMDATAB.GRP file onto the diskette. Then 
copy this file to the server's drive D: FILESET WINDOWS. Or you can do this 
COPY operation on the server. 
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In this section, we discuss DB2 related files you will be confronted with while 
setting up DB2 for remote IPL. More detailed information is given in the actual 


DB2 manuals, such as: 


S20H-4580-00 
Version 2 


S20H-4645-00 
Version 2 


* S20H-4785-00 
Version 2 


* S20H-4782-00 


* S20H-4789-00 
Version 2 


DATABASE 2 Administration Guide for common servers 


DATABASE 2 Command Reference for common servers 


DATABASE 2 for OS/2 Installation and Operation Guide 


DATABASE 2 Installing and Using OS/2 Clients Version 2 
DATABASE 2 Installing and Using DB2 Clients for Windows 


Following is a short description of two major DB2 related parameter/files: 


(File) Name 


DB2SYSTM 


DB2INSTANCE 


Description 


This is a database manager configuration file. This 
contains the information of a specific CAE workstation. 
There is only one database manager configuration file for 
each CAE installation. 


An instance at the client can be thought of as an 
environment in which you want to run your database 
applications. There must be at least one instance defined 
on the workstation in order to perform any operations. 
One instance is created for you when a client is installed 
and the name of this default instance is DB2. On a client 
only workstation (that is, no DB2 for OS/2 installed) there 
can be only one Windows client instance. 


Following is the description of the DB2.INI file that is used for the Windows 


environment: 
Parameter 
DB2INSTANCE 


DB2INSTPROF 
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Description 


This specifies the instance that is active by default. This 
must be set to a valid instance to perform any DB2 
operations. For DB2 Client for Windows, only one active 
instance, DB2, is allowed. Note that this corresponds to 
the DB2 instance directory. 


This points to the instance profile directory, which is 
different from the install directory. This is mandatory for 
this implementation in order to separate the instance 
profile directory from the install directory. Note that this 
should be set to the remote IPL user's instance profile 
directory which is the home directory, for example: 

H: SQLLIB. 


During the execution of certain DB2 functions such as 
LOAD, temporary files are created in the instance profile 
directory. In such case, performance will be better if the 
instance profile directory points to the local drive such as 
C:. 


DB2PATH This specifies the directory where the product is installed. 
Note that this should be set to the logical directory from 
the remote IPL machine's perspective for example: 

W: SQLLIB WIN. 


DB2CODEPAGE This keyword must be set when connecting to a server that 
does not have unequal code page support, such as DB2 for 
OS/2 Version 1. 


This keyword specifies the code page of the data 
presented to DB2 for OS/2 by the windows database client 
application. The user must set this keyword to the correct 
code page to which applications convert data. This code 
page must also match the code page of the database 
being accessed in order for the database server to allow 
access. 


For Windows, if the DB2CODEPAGE environment keyword 
is set, its value is taken as the application code page. If 
DB2CODEPAGE is not set, the windows code page is 
derived from the country ID as specified in the icountry 
value in the [int1] section of the windows WIN.INI file. 


DB2YIELD=Y This specifies the behavior of the Windows remote IPL 
client while communicating with a remote DB2 server. If it 
is not set to Y, the client will not yield CPU time and 
control to other Windows applications. 


ODBC INI Files Examples 
Following is an example of the H: WINDOWS ODBC.INI file: 














[ODBC Data Sources] 
Student Registration=Access Data (*.mdb) 
SAMPLE=IBM DB2 ODBC DRIVER 












































[Student Registration] 
Driver=W: \WINDOWS\simba.d11l 
FileType=RedISAM 
SingleUser=False 
UseSystemDB=Fals 





























[SAMPLE] 
Driver=W: \WINDOWS\DB2CLIW. DLL 
Description=Sample DB2 Client/Server database 
































Figure 210. ODBC.INI File Example 


Following is an example of the H: WINDOWS ODBCINST.INI file: 

















[IBM DB2 ODBC DRIVER] 
Driver=W: \WINDOWS\DB2CLIW. DLL 
Driver=W: \WINDOWS\DB2O0DBC. DLL 

































































[ODBC Drivers] 
TBM DB2 ODBC DRIVER=Installed 









































Figure 211. ODBCINST.INI File Example 
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Currently there are two known defects in DB2 CAE V2.1.0 which should be fixed 
in the future release. However, workarounds are described here: 


1. Binding your application using the Client Setup Utility 


If you are trying to bind your application programs using the Client Setup 
utility, you will experience the following problem: The Client Setup utility 
creates temporary files and messages files from any bind operation in 
the DB2 installation directory. So far, these bind output files cannot be 
redirected. Since the redirected DB2 installation directory (in our 
example it is the W: SQLLIB directory) is a read-only directory, the bind 
operation will fail. 


Workaround: You should bind applications from the Windows DB2 
Command Line Processor and either omit a messages 
parameter, or specify a bind message file that is in a 
directory the client can write to. For example: H: SQLLIB 


2. DB2 ODBC Installer 


If your redirected Windows drive (in our example W: WINDOWS) is 
accessed as a root drive (just W: ) the DB2 ODBC Installer will fail with 
an error message since it could not open W: DB2CLIW.DLL. 


Workaround: You should create your Windows shared resource as it is 
described in this chapter or set up the ODBC environment 
manually and have a look at the examples shown in 
“ODBC INI Files Examples” on page 357. 


Other problems to watch for: 


1. DB2IDIR must exist in the path specified by the DB2INSTPROF parameter in 
the DB2.INI file. An error message could appear claiming that the instance 
directory cannot be found or is invalid. 


2. The instance directory specified by the DB2INSTANCE parameter in the 
DB2.INI file must be set to DB2. The instance directory must exist in the path 
specified by the DB2INSTPROF parameter in the DB2.INI file. An error 
message could appear claiming that the instance directory cannot be found 
or is invalid. 
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Chapter 16. OS/2 LAN Server 4.0 CID Enablement 


This chapter describes the CID implementation of OS/2 LAN Server 4.0. 
Software distribution has become a more and more important issue in choosing 
the right operating system and the right network operating system (NOS) for 
clients and servers. This chapter will cover OS/2 implementations as well as 
DOS implementations. The network operating system covered here is OS/2 LAN 
Server 4.0 Advanced. The software discussed here, which will be set up for 
remote installation, is: 


OS/2 2.11 
OS/2 Warp Version 3 
Multiprotocol Transport Services 
OS/2 LAN Server 4.0 
NetView Distribution Manager/2 2.10 
IBM PC DOS 6.3 
DOS LAN Support Program 1.36 
DOS LAN Services 
Additional support for remote installation of, for example, Communications 


Manager/2 1.11 or DB2/2 has to be added separately. You can use the profiles 
discussed here as templates. 





Available Software Distribution Managers from IBM 


© Copyright IBM Corp. 1995 


The programs that automate software distribution via LANs by using redirected 
installation and configuration of CID-enabled products are: 


LAN CID Utility (native) 
CASSETUP with LAN CID Utility (LCU) 
NetView Distribution Manager/2 2.10 


Both, LAN CID Utility and CASSETUP come with the OS/2 LAN Server 4.0 product 
and allow you to perform a series of ClID-enabled OS/2 product installations. 

The program that handles redirection is the Service Installable File System 
(SRVIFS). LAN CID Utility is a Software Distribution Manager that redirects 
product installation files to clients by using SRVIFS, a NetBIOS application, over 

a LAN. 


LAN CID Utility is comprised of REXX procedures and several supporting 
modules that track the current state of an installation across reboots and ensure 
that each step is run in the proper sequence. Once the desired sequence is 
defined to LAN CID Utility, the installation process runs to completion without 
user involvement (assuming no errors are encountered). 


CASSETUP is a Presentation Manager front-end to LAN CID Utility that can help 
the administrator fulfill preparation tasks. With CASSETUP, the administrator is 
not confronted with REXX because it generates REXX LCU command files 
necessary for remote installation. So far, CASSETUP and LAN CID Utility only 
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support OS/2 workstations to be installed remotely. Applications that are to be 
installed remotely must be ClD-enabled. 





-—— Definition of ClID-enabled Products 


A ClD-enabled application supports remote installation when it can use a 
redirected drive for installation and a response file to omit user interaction. 











NetView Distribution Manager/2 2.10, which is a separate product, allows you to 
perform a series of ClD-enabled and non-ClD-enabled DOS and OS/2 product 
installations. There is no need for additional utilities to establish redirection 
since NetView DM/2 handles redirection by itself. Also, there are no REXX 
procedures necessary to start and track remote installations. NetView 
Distribution Manager/2 2.10 stores workstation information and information of 
distributed software in a DB2/2 database. Like CASSETUP and LAN CID Utility, 
NetView Distribution Manager/2 2.10 also uses NetBIOS as the file transfer 
protocol. This especially must be considered when other NetBIOS applications 
like Lotus Notes, Time & Place, OS/2 LAN Server 4.0 etc. have to run on the 
same machine. A second LAN adapter might be necessary to have more 
NetBIOS resources available. 


Software distribution managers use the CID architecture that allows software to 
be installed remotely, using redirected drives and response files. Response files 
contain the answers to installation questions a user usually has to answer 
interactively while he is installing the product. Using response files enables 
unattended software distribution, meaning no other user is required. 


The LAN administrator has to perform a certain number of preparation tasks to 
set up a software distribution environment. Independent from the Software 
Distribution Manager, the administrator must: 


Create a code server subdirectory structure. 

Load the product diskette images to the code server. 

Enable the code server for remote installation. 
* Create client boot diskettes for diskette-initiated workstations. 
* Build product-specific response files. 


Build client-specific LCU command files if LCU is the Software Distribution 
Manager. 


Only LAN CID Utility and CASSETUP are included in the OS/2 LAN Server 4.0 
package. NetView Distribution Manager/2 2.10 is a separate product to be 
bought. All three software distribution mangers support the CID architecture. 
Table 21 on page 361 contains a short description of the three products. 
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Table 21. IBM's Software Distribution Managers and Their Features 


Software Distribution Manager 


Features LAN CID Utility CASSETUP NVDM/2 2.1 
Extended. 


Object Oriented (Drag and Drop) ee a - 
Command Line Interface (CLI) a eee ee 0 
Response File Generator a (ee) - 
OS/2 CID Software Distribution a en a 
DOS CID Software Distribution a ee 
Non-CID Software Distribution a ee 
UAN Suppor (2 wr Oe 
Additional Products needed he a DB2/2 


CASSETUP with LAN CID Utility is a good software distribution solution for 
smaller LANs in that it is easy to set up and usually has sufficient function. 
NetView Distribution Manager/2 2.10 is designed for larger LANs with enterprise 
wide network connections. You need to have DB2/2 installed on your NVDM/2 
server. For smaller LANs, the NetView Distribution Manager/2 2.10 solution may 
be quite an expensive solution since requesters (clients) have to have special 
client software installed. However, it certainly is a professional solution. 

Another nice feature of NetView Distribution Manager/2 2.10 is the license 
management feature since it keeps track of distributed software. 


O:] Or} Or] O: 











Setting Up a Code Server 


There are common tasks a LAN administrator has to perform besides deciding 
which Software Distribution Manager to use. 


Code Server Directory Structure 
Code Server Directory Structure 





Before you implement your software distribution environment, no matter what 
kind of Software Distribution Manager you are going to use, you must first 
consider what type of directory structure you want on the code server. 





The directory structure determines where the product images, and other files 
that are needed for remote installation, are located so that LAN CID Utility, 
CASSETUP or NetView DM/2 can find them. 


In the example, as shown in Figure 212 on page 362, the directory structure can 
be used by NetView DM/2, CASSETUP, and LCU. 


This chapter assumes that you plan to follow the recommended directory 
structure. If you have created or if want to create a directory structure other 
than the recommended directory structure, insert your own directory names 
whenever necessary. 
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d:\- 
— SHAR: 





eal 
> 
I 


- CLIENT 
- DLL 




















- IMG - 





- SHAREB - 








- FSDATA 





v211 
Vv30 


MPTS 
v211 
Vv30 


- PROFILES 


DLS 

LCU 
LS40A 
LSP136 
MPTS 
NVDM2V21 
os2v211 
0S2V30 
IBMDOS 63 
SRVIFS 





DLS 
LSA40 
LSP136 
MPTS 
NVDM2V21 
os2v211 
0S2V30 
IBMDOS63 





DLS 

LCU 
LS40A 
LSP136 
MPTS 
NVDM2V21 
os2v211 
0S2V30 
IBMDOS 63 
SRVIFS 





/* Client Command Files 

/* Dynamic Link Libraries for LCU 
/* OS/2 2.11 related 

/* OS/2 Warp Version 3 related 

/* Executable Files for LCU 

/* MPTS related 

/* OS/2 2.11 related 

/* OS/2 Warp Version 3 related 





/* NVDM/2 Change File Profiles 


/* Product Diskette Images 

/* DOS LAN Services 

/* LAN CID Utility 

/* OS/2 LAN Server 4.0 Advanced 
/* DOS LAN Support Program V1.36 
/* Multiprotocol Transport Services 
/* NetView DM/2 V.2.1 Extended 
/* OS/2 V.2.11 

/* OS/2 Warp V3 

/* IBM PC DOS 6.3 

/* Mini-Server/Requester Utility 





/* Product Specific Response Files 
/* DOS LAN Services 

/* OS/2 LAN Server 4.0 Advanced 

/* DOS LAN Support Program V1.36 

/* Multiprotocol Transport Services 
/* NetView DM/2 V.2.1 Extended 

/* OS/2 V.2.11 

/* OS/2 Warp V3 

/* IBM PC DOS 6.3 





/* Log and History files 

/* DOS LAN Services 

/* LAN CID Utility 

/* OS/2 LAN Server 4.0 Advanced 
/* DOS LAN Support Program V1.36 
/* Multiprotocol Transport Services 
/* NetView DM/2 V.2.1 Extended 
/* OS/2 V.2.11 

/* OS/2 Warp V3 

/* IBM PC DOS 6.3 

/* Mini-Server/Requester Utility 





Figure 212. Code Server Directory Structure Example 








-—— What is drive d:? 





In figures, examples and syntax diagrams that are shown in this chapter the 
drive letter d: (always written in lowercase) is the code server's drive letter. 








The following is a description of the directories found in the recommended 
directory structure and the intended contents of the directories. 
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Table 22. Description of the Recommended Directory Structure 
Directory Name Description 


SHAREA The user-defined name of the root directory for all but the log directories 
in the recommended structure. 


SHAREB The user-defined name of the root directory for the log directory in the 
recommended structure. 


CLIENT The client directory containing the command files that LAN CID Utility is to 
use for the redirected installations on the clients. These can be specific 
client command files, default command files or both. 


DLL CASSETUP and LAN CID Utility need additional OS/2- and REXX-related 
dynamic link libraries in order to work properly. For each OS/2 version, 
there is another subdirectory to this path and directory. 


EXE CASSETUP and LAN CID Utility need additional OS/2 and REXX 
executable files in order to work properly. For each OS/2 version, there 
is another subdirectory to this path and directory. 


PROFILES Change file profiles for NetView DM/2. These are product-specific files 
that contain syntax of the remote installation program and are needed to 
build a CDM software catalog. 


FSDATA File services for NetView DM/2. These are the product-specific change 
files. (Files are called change files because software distribution is part 
of IBM's NetView Family. The discipline's name is change management) 


IMG The product images directory containing a subdirectory for each product. 


RSP The response files directory containing a subdirectory for each product. 
The individual product subdirectories hold the general response files, the 
individual client response files and the default response files for that 
product. Not all programs use response files. For example, the LAN CID 
Utility installation program, CASINSTL, and the SRVIFS requester 
installation program, THINIFS, do not. 








LOG The log directory containing a subdirectory for each product. 








Setting Up a Code Server with the CASSETUP Utility 


CASSETUP provides a single graphical interface for several common tasks 
involved in installing ClID-enabled products over the network. 












a 
Code Sener 
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Multi-Protocol Transport oOs/2 
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Figure 213. CASSETUP Code Server Setup Utility 
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CASSETUP allows you to: 


Install the means of redirection SRVIFS (a simple server) 
Run the LAN CID Utility (LCU) 


Load product diskette images from diskettes or CD-ROM onto a Code Server 


* Build LCU boot diskettes for diskette-initiated clients 


+ Create CASPREP files which can be used to generate the client-specific LCU 
command files 


CASSETUP generally can handle all kinds of ClD-enabled applications. To add 
an application to the suite that CASSETUP understands, you just add an 


application (.PRO) profile to the CASSETUP directory. As described in the 
following pages, the CASSETUP directory in our following example is d: CASTLE. 


Similarly, to build boot diskettes of different OS/2 versions, you just create a 


diskette-built (SCR) script file, using the provided script files as templates. 


Installation of the CASSETUP Utility 


Before you proceed with the next steps, make sure you have created the 
recommended directory structure discussed in “Code Server Directory 


Structure” on page 361. 


1. Create a directory for example D: CASTLE. 
2. Unzip CASSETUP.ZIP file from the third MPTS diskette image. 





--PKUNZ 





P2¥: \ 





MG\LS40A\ 














BM400N3\APPLI 








ETS\CASS 











ETUP.Z 








p-- 


3. If you plan to use CASSETUP under OS/2 Warp, make sure you have the 
latest version of CASSETUP available. The version that comes with the 
product will hang when started on a OS/2 Warp machine. The updates files 
known as APAR ICO8609 and IC08610 are: 





CASSETUP. 








AXE 








0S230.PRO 


30NNTS.SCR 


(10/28/94 version or later) 


Generally two modifications to CASSETUP files should me made. 


a. First change a REXX statement in the CASENG3.CMD file. Using an 


ASCIl editor like EPM goto the line 627 and change following statement: 


logpath = leudrive 


to: 


logpath = logdrive 


Unless you make this change all clients being remotely installed will 


have read/write access to the product image tree. 


b. Secondly make following changes to the CASENG6.CMD file. Load this 
file using an ACII editor and goto line 1003. Look for following section: 
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D: \CASTLI 


























'/11:'glob.lcualias.0Drive':\' 


STRIP(glob.lcupath,'b','\') || "\" 
'LOG\lcu\"client".log 
'/12:'glob.leualias.0Drive':\' 

"" THEN 
STRIP(glob.lcupath,'b','\') || "\" 
'LOG\lcu\srvifs_req.log 
'/req:"client"' 











TheCmd = TheCmd 

IF glob.1lcupath <> "" THEN 
TheCmd = TheCmd 

TheCmd = TheCmd 

TheCmd = TheCmd 

IF glob.lcupath <> 

TheCmd = TheCmd 

TheCmd = TheCmd 

TheCmd = TheCmd 


and make following changes to this section: 











Unless you make this change logfiles cannot be written, since Icudrive is 











'/11:'glob.logalias.0Drive':\' 


STRIP(glob.1lcupath,'b','\') || "\" 
"LOG\1lcu\"client".log 
'/12:'glob.logalias.0Drive':\' 

"" THEN 
STRIP(glob.1lcupath,'b','\') || "\" 
'LOG\lcu\srvifs_req.log 
'/req:"client"' 











TheCmd = TheCmd 

IF glob.1lcupath <> "" THEN 
TheCmd = TheCmd 

TheCmd = TheCmd 

TheCmd = TheCmd 

IF glob.lcupath <> 

TheCmd = TheCmd 

TheCmd = TheCmd 

TheCmd = TheCmd 


a read/only area whereas logdrive is not. 


4. From the D: CASTLE directory, issue the following installation command 
from an OS/2 command line: 


--CASINST 


A Code Server Setup icon will appear on your desktop when the installation 








of CASSETUP is complete. 


5. Shutdown and reboot your workstation as prompted. 


Modify the CASSETUP.STR Storage Information File 
Before you actually load the CASSETUP code server setup utility, we recommend 
you adapt the storage information file CASSETUP.STR to your CID environment. 

Alternatively, you may use the application features of CASSETUP to modify 
default values. 


Change to the d: CASTLE directory, and edit the file CASSETUP.STR by using an 
ASCII editor, such as EPM. Considering the proposed subdirectory structure 


shown in Figure 212 on page 362, alter the entries as highlighted and shown in 


Figure 214 on page 366. 
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Server. 

srvname=PARIS 

srvgroup=0 

imgalias=IMAGES 

srvicon=CASSETUP: #108 

Alias. 
aliasname=LOGFILES 
aliasdrive=D: 
aliaspath=\SHAREB 
aliasro=0 

endalias. 

Alias. 
aliasname=IMAGES 
aliasdrive=D: 
aliaspath=\SHAREA 
aliasro=1 

endalias. 

Srvits; 
srvifsflag=0 
maxfiles=100 
maxsessions=5 
maxthreads=10 
adapterno=0 
clientdrive=c 
diraccess= 
perclient=0 
serverpath=C: \SRVIFS 

LCUpath= 
LOGA1ias=LOGFILES 
RSPA1ias=IMAGES 
CMDA1ias=IMAGES 
WRKAlias=IMAGES 
DLLA1ias=IMAGES 
LCUA1Lias=IMAGES 
Cmddir=CLIENT 

Endsrvifs. 

Endserver. 

















Figure 214. CASSETUP Storage File CASSETUP.STR 


Note: The server name (srvname) must be a unique name, that means not used 
by other NetBIOS applications such as LAN Server/Requester, and must not 
exceed 8 bytes (characters or numbers). 





-—— Reminder: Directory Structure 


Make sure all directories mentioned in the CASSETUP.STR file exist. 
Otherwise, some parts of the installation may fail. 











Selecting Application Profiles 

The code server utility comes with a series of application profile (.PRO) files 
which are installed by the CASINST command. Profile files that you do not use 
must be moved to another directory, for example d: CASTLE TEMPLATE. 
Otherwise, they will appear in the Applications Container of CASSETUP. 


In this example, we used the following highlighted profiles: 
































LS40A.PRO OS/2 LAN Server 4.0 Advanced (whole product) 

LS40E. PRO OS/2 LAN Server 4.0 Entry (whole product) 
LS40AREQ.PRO OS/2 LAN Server 4.0 Advanced (Requester part) 
LS40AREQ. PRO OS/2 LAN Server 4.0 Entry (Requester part) 
LS40CDA. PRO OS/2 LAN Server 4.0 Advanced (whole product) from CD 
LS40CDE. PRO OS/2 LAN Server 4.0 Entry (whole product) from CD 
MPTS10.PRO Multiprotocol Transport Services 

0S221.PRO OS/2 2.1 
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0S2211.PRO OS/2 2.11 
O0S221SP.PRO OS/2 2.1 Service Pak XR06200 
0S230.PRO OS/2 Warp Version 3.0 





Non-highlighted (.PRO) profile files are moved to the CASTLE TEMPLATE 
directory. 


Creating Additional Application Profiles: \f you want to distribute OS/2 Warp 
Version 3 as well, you can easily create its application profile by doing the 
following: 


1. In the CASTLE directory, copy the file OS2211.PRO to 0S230.PRO. 


2. Edit the OS230.PRO file, and change the following values as shown in 
Figure 215, 





PPNAME 
PPNICK 
KKKKKK 
PPDIR = IMG\OS2V30 
ORKDIR = EXE\V30 

LLDIR = DLL\V30 

ESPDIR = RSP\OS2V30 
LOGDIR = LOG\OS2V30 


OS/2°Warp, Version 3 
0S230 


KKK KKK KK KKK KKKKKKKERK 














DOS Dy + DD 

















Figure 215. CASSETUP Profile for OS/2 Warp Version 3 (OS230.PRO) 


and replace all OS/2 2.11 entries with OS/2 Warp Version 3. 





Note: The alias name, WORKDTIR, points to the code server directory 
SHAREA EXE. 








Creating Additional Boot Diskette Script Files: \n order to create a set of OS/2 
Warp Version 3 boot diskettes, you need to add the following boot diskette script 
file: 


1. In the CASTLE directory, copy the file 211NNTS.SCR to 23NNTS.SCR. 
2. Edit the 283NNTS.SCR file, and change values as shown in Figure 216. 


Title: OS/2 Warp Version 3 and MPTS 1.0 
Desc: 
Build boot diskettes with OS/2 Warp Version 3 and MPTS 1.0 
EndDesc: 
* This is a comment line 
* The next line causes a prompt for a diskette to be 
* issued: 
*Prompt: Programs Diskette #1 
* This next line allows us to put up a warning message if needed 
*Warn: Creation might fail due to lower OS/2 level.~Press OK to continue. 
* The next line does a verify step. If it fails, the 
* previous line is executed again. You can choose to 
* verify either the volume label or a file or nofiles 
* 
* 








by the arguments VOLSER label, FILE filename, or 
BLANK 





Figure 216 (Part 1 of 2). Create Boot Diskette Profile for OS/2 Warp Version 3 
(23NNTS.SCR) 
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*Verify: FILE anyfile.txt 

* The next lines executes steps: 
OS: 2 0s230 
TRANSPORT: 2 mpts10 SN=NIFFILESPEC 
lines of this sort have a type followed by a colon, 
then an integer then a label. The label is the 
nickname of an application loaded on the code server 
using CASSETUP. The integer is the 
ordinal of the maintenance-system building command 
in the profile. The rest of the line defines 
symbolic substitutions. The left side is the string 
to be replaced on the command line; the right is 
the name of an environment variable that contains 
the data to be substituted. 























+ + FF F F F F F HF 











Figure 216 (Part 2 of 2). Create Boot Diskette Profile for OS/2 Warp Version 3 
(23NNTS.SCR) 


t— Note Concerning DOS Remote IPL Feature of OS/2 LAN Server 4.0 


Using CASSETUP, you cannot remotely install LS 4.0 with the DOS Remote 
IPL feature. This is due to CASSETUP's own transfer procedure. It does not 
use the LANINST command of OS/2 LAN Server 4.0 to transfer product 
diskettes for remote installation. Therefore, you cannot get prompted for any 
DOS version to be supported with OS/2 LAN Server 4.0. 





Working with the CASSETUP Utility 

Prior to starting the CASSETUP utility, you have to enable your code server for 
remote installation. That means you have to have Multiprotocol Transport 
Services loaded on your code server, configured with the NetBIOS network 
protocol. Check “Selecting Network Protocols for Remote Installation” on 

page 379 for more information. 


Start the CASSETUP utility by double-clicking on its Code Server Setup icon. 
While loading, it reads profile and storage information you adapted, selected, 
and added in the steps before. From the Code server setup utility folder, open 
the Applications and Code Servers objects. 
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Figure 217. CASSETUP Containers 


1. Load LAN CID Utility and SRVIFS. 


a. Within the code server container, pull down the Selected menu. 





4 
4 
 ceecccecrccecracciid 


Figure 218. Code Servers Container Selected Menu 


b. Select Srvifs/LAN CID utility support. 
c. Then select Load... 


The Load Srvifs/LAN CID utility support window will be opened. This 
window is shown in Figure 219 on page 370. 
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Us 





SRVIFS server target path: 








LAL | 
SRVIFS client ¢ LAN CID utility target: 
Alias: IMAGES (Read-Only ) DB: \SHARFA 








Figure 219. Load Srvifs/LAN CID Utility Support Window of CASSETUP 


d. Select the OK button to start the installation process (you do not need to 


insert a path since the IMAGES alias already points to the SHAREA 
directory). 


LAN CID Utility and SRVIFS is being installed on the code server. Insert 
the third MPTS diskette when prompted. After successful completion, the 
following information window will pop up on your screen to prompt you 

to stop the code server utility and to restart the workstation: 





The subdirectory, C:A\SRVIFS, has been 
added to the PATH= and DPATH= 
Statements in CONFIG.S¥S. 


Stop the Code Server Setup Utility, then 
shutdown and restart this workstation. 


STARTUP.CMD was also Updated. 





Figure 220. Load Srvifs/LAN CID Utility Support - CONFIG.SYS Modified Window 
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According to the changes made to the CASSETUP.STR file, the following 
initialization SERVICE.INI file was created for SRVIFS: 


Name = PARIS 

GroupName = no 

Adapter = 0 

MacClients = 5 

MaxFiles = 100 

ClientWorkers = 10 

Path=D: \SHAREA 

PermitWrite = no 

PerClient = no 

ALIAS=READWRITE, SINGLE, LOGFILES, D: \SHAREB 
ALIAS=READONLY, SINGLE, IMAGES,D: \SHAREA 



















































































After restart of the workstation, SRVIFS-Server will be started from the 
STARTUP.CMD. 


2. Upload and register the products. 


a. From the applications window (suite), drag the desired product object 
you want to make available for remote installation to the code server's 
icon in the code server's window (suite). For example, drag the OS/2 
Warp Version 3 object, and drop it to the server's object, PARIS. 


The Application Image Load window will be opened as shown in 
Figure 221. 







Application: 





Operation: Loac v2 Register 

Nick name: O8250 

Image SourCe AN errr 
Teroete ues Pee 

image: MAGES 

Work: IMAGES 

Bu: IMAGES 


Response files: IMAGES IRSP\OS2V30 


Log files: LOGFILES LOG\OS$2V30 


Cancel —§ Help | Alias definitions... | 





peepee penecronnntrnetmm nenemnt peered: Dib ennennaneerie eer noeteninanneron ence nantennnnne oe nenmrnoed 


Execute image load programs 


Figure 221. Application Image Load Window of CASSETUP 


The Operation attribute allows you to select between Load and Register. 
Select either: 


Load - When you want to upload the product diskette images to the 
code server's directory (in this case select this option). 


Register - When you only want to register the product since the 
product has already been uploaded (that means the CID tree with the 


product images must have been created before with the CASSETUP 
utility). 


All entries are retrieved from the (.PRO) profile files and the 


CASSETUP.STR file you adapted in the steps before. Therefore, you do 
not need to change the field's values. 


Select OK to start the operation and insert diskettes as prompted. 


3. Same procedure for all other products that are available in the applications 
window (suite). But consider this exception: 


Prior to uploading LS 4.0 Requester, you have to load the whole LS 4.0 
Advanced Server product. When doing this, just select Register at the 
Operations statement radio button to register LS 4.0 Requester, since LS 4.0 
code, which includes the LS 4.0 requester diskettes, has already been 
uploaded. 


Before registering the MPTS product, you must manually do the following 
because these steps are executed during the load function. 
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MG LCU 








PKUNZIP2 D: SHAREA IMG LS40A IBM400N3 LCU LCU.ZIP D: SHAREA 























PKUNZIP2 D:\SHAREA\IMG\LS40A\IBM400N3 \APPLETS\MPTSAPLT. ZI 


























D: \SHARE 


























A\ 





LAPSRSP C:\IBMCOM\PROTOCOL.INI D:\SHAREA\RSP\MPTS10\DEFAULT.RSP /T:D: 























The following commands will be executed as a part of OS/2 loading, but not 
with the REGISTER function, so you must manually run the following 
commands from D: CASTLE directory: 
































GetOSCid D: SHAREA IMG 0S2V30 D: SHAREA EXE V30 
GetREXX D:\SHAREA\IMG\OS2V30 D:\SHAREA\DLL\V30 
GetBOOT D:\SHAREA\IMG\OS2V30 D:\SHAREA\EXE\V30 
























































4. You now may check to see if all applications uploaded in the steps before 
are available at the code server's tree. Therefore, expand the tree of code 
server PARIS. 





dy 








: OS/2 
ot Warp, Version 3 


fp OS/2 
Version 2.14 


Multi-Protocol Transport 
| Services 1.0 


LAN Server 4.0 
Advanced 


gage LAN Server 4.0 
Y. Advanced-Requester 








secieiith 


Figure 222. Available Applications at Code Server PARIS 
5. To create client boot diskettes for pristine installations, perform following 
steps: 
a. Open the code servers window (suite). 
b. Pull down the Selected menu (see Figure 218 on page 369). 
c. Select Create client (boot) diskettes... 


The Create Client (boot) diskettes window will be opened (which is 
shown in Figure 223 on page 373). 
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223. Create Client (Boot) Diskettes Window of CASSETUP 


. Select the correct configuration, ID method and adapter type from the 
pull down menus. If you select Prompt as ID method, the IPLed client 
will prompt for the client's name. Otherwise, select Client and enter the 
client's name. When all selections are made, select the OK button. The 
boot diskette creation utility prompts you for two diskettes. While 
creating the boot diskettes, the following steps will be done without user 
interaction: 


Creation of a pair of OS/2 boot diskettes 

Installation of MPTS-LAN Adapter and Protocol Support 
Installation of the Mini-SRVIFS requester 

Installation of LAN CID Utility 


ter successful completion of the client boot diskette creation, select Cancel 
close the window. 


6. To create client specific LCU command files for remote installation, open the 
code servers container Selected menu (see Figure 218 on page 369) and 
select Create Casprep/Command files..... The LAN CID Utility 
casprep/command files window will be opened (which is shown in Figure 224 
on page 374): 
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Select applications to include: 


Application Target Path 






: LR A 
Note: Use "All+mousebuttoni" to edit the target 


path, Use the numeric key pad ‘Enter’ key to 
Update the changes, 





Generated casprep file: 






Generate LAN CID Utility Casprep k file, 





Convert casprep file to _ Command _ fle. 





Figure 224. LAN CID Utility Casprep/Command Files Window of CASSETUP 


a. Select the applications you want to install remotely. 


b. Change the target path, if necessary. To edit the target path, use 
Alt+left mouse button. The path gets updated when you press the 
numeric Enter key (which is the very right Enter key). 


c. Select Generate LAN CID Utility Casprep file. 


This procedure invokes generation of a LAN CID Utility Casprep file that 
can be converted to the LAN CID Utility client command file. If OS/2 is 
selected as an application to be installed remotely, an additional dialog 
window will be displayed to provide information for the process to create 
a maintenance system. A maintenance system is needed, for example, 
for applications that are to be installed remotely but do not need, or must 
not have, Presentation Manager active. If such a dialog window (shown 
in Figure 225) is displayed, select the correct target operating system 
and select the OK button. 







yu 
Maintenance system parameters: 


 DrVesi 
Boot: Maintenance system: 


Operating system level 








Figure 225. LAN CID Utility Casprep File Dialog Window 
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After the generation of the casprep file, you should get an information 
window that displays a successful completion. 


d. Now select Convert casprep file to Command file. From the Select 
CASPREP source file window (which is shown in Figure 226), select the 
LCU.pre file you want to convert into a LCU client command file. 





| Open filename: 
_ ITSCWKO1.PRE 


TUpe of file: 
<All Files > 


§ 





Figure 226. Select CASPREP Source File Window 


Select OK. 


After successful completion, the information window shown in Figure 227 
is displayed. 





Ce 


| LAN CID Utility command file 
oO (DO \SHARE A\CLIENTNITSCWROI.CMD) 
created. 





Figure 227. LCU.CMD Information Window 


7. Select Cancel at the LAN CID Utility casprep/command files window if you 
are finished with creating client LCU command files. 


8. You now may check the newly created client LCU command file for the 
workstation called ITSCWK01. Change to the code server's directory to show 
d: SHAREA CLIENT and edit the ITSCWK01.CMD file. 


9. Before you start your remote workstation, you must create product specific 
response files adapted to the client's needs. See “Creating Product Specific 
Response Files” on page 399 for information on how to do it. 


10. You may now start your remote workstation with the client boot diskettes. 
Enter the workstation name ITSCWKO1 when prompted. 
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Setting Up a Code Server Manually 


Instead of using the CASSETUP utility, you may manually set up your CID 
environment. You might get a better understanding about the CID process since 
you are involved with all kinds of installation processes while enabling your code 
server. 





-—— Reminder: Directory Structure 


Make sure that at all directories shown in Figure 212 on page 362 exist. 
Otherwise some parts of the installation might fail. 











Loading OS/2 Diskette Images to the Code Server 


The following steps are necessary for NetView DM/2 and LCU: 


Note: Adapt the target directory name if you transfer OS/2 Warp Version 3 
code. For example, use V30 as the target directory name instead of 
V211. 


1. Unpack the file named CID from Diskette 7 of OS/2 2.11. 











--UNPACKA: \CID--d: \SHAREA\EXE\V211 - - - - - - 




















The files SEMAINT.EXE, SEINST.EXE, SEDISK.EXE and SEIMAGE.EXE are 
extracted. 


2. Leave diskette 7 of OS/2 2.11 in your diskette drive and invoke: 




















--UNPACKA: \REQUIREI. \SHAREA\EXE\V27N+RSPINST. EXE = = = 





























3. In order to transfer the OS/2 product diskette images onto the code server 
invoke the following command: 











--d: \SHAREA\EXE\V211\SEIMAGEFA:—/T:d: \SHAREA\ IMG\0OS2V211--------- 





a 


























Insert product diskettes as prompted. If you transfer OS/2 Warp Version 3 
code, you will be asked: 


seimage - Would you like to create a tree structure for Windows 
diskettes? (Y/N): 


Answer this question with y. The next question you will get is: 








seimag Enter a Windows subdirectory name if desired. This 
will be appended to the current target directory. 


You do not have to enter a subdirectory name. Just press the Enter key. 
Insert Windows product diskettes as prompted. After the Windows product 
diskettes have been transferred, you will be prompted to answer this 
question: 


seimage - Would you like to create a tree structure for another 
Windows package? (Y/N): 


If you use different Windows versions in your network, for example 3.1 and 
3.11, answer this question with Y, and type in a subdirectory name 
afterwards. Otherwise, type in N. 
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OS/2 Remote IPL Support 


If you plan to enable RIPL support for OS/2, insert diskette 7 in drive A: and 
invoke the following command: 








--UNPACK-A: \RIPLINS& \SHAREA\EXE\V211---- = SS SSeS SoS SSS Sse Sse 


























The files RIPLINST.EXE and RIPLINST.HLP are extracted. 


Note: When using OS/2 Warp Version 3, use SHAREA EXE V30 as the target 
directory instead of SHAREA EXE V211. 


Loading OS/2 LAN Server 4.0 Diskette Images to the Code Server 


The following steps are necessary for NetView DM/2 and LCU: 


In order to transfer the IBM OS/2 LAN Server 4.0 product diskette images onto 
the code server, insert the first server diskette in drive A: and invoke the 
following command: 


--A:\LANINST- - - - - Seee= pie ess Sea eae _ 








Select tailored installation/configuration path. Select Copy product diskettes for 
remote installation. At the Copy Product Diskettes window you may select: 


* LAN Services if you want to copy LAN Services product diskettes to the 
remote installation subdirectory 


DOS to get a list of supported DOS versions from which you select the DOS 
version(s) you want to copy to the remote installation subdirectory. 
Supported DOS versions are: 


- IBM DOS 3.3, 5.0, 6.1, 6.3 
- MS DOS 3.3, 5.0, 6.0, 6.2 
Enter the path d: SHAREA IMG LS40A on the Remote Install Subdirectory 


window where the OS/2 LAN Server 4.0 product diskette images are to be 
copied. Insert product diskettes as prompted. 


Loading MPTS Diskette Images to the Code Server 
The following is necessary for NetView DM/2 and LCU. 


Though OS/2 LAN Server 4.0, along with the MPTS diskette images, has already 
been transferred to the code server, the MPTS product diskette images have to 
be transferred as a separate product as well. Insert the first MPTS diskette in 
drive A: and invoke following command: 














--A: \LAPSDISKA: --d: \SHAREA\IMG\MPTS----- S = a = a all al ot ae 














Insert second product diskette as prompted. 
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Loading the LCU Utility to the Code Server 


The following steps are necessary for LCU only: 
1. Unzip the file named LCU.ZIP from the third MPTS diskette. 








--PKUNZIP2A: \LCU\LCU. ZIP--d: \SHAREA\ IMG\ LCU------------------------- 




















Leave the diskette in your diskette drive and continue as follows. 
2. Partly unzip the file named MPTSAPLT.ZIP 





--PKUNZIP2A: \APPLETS\MPTSAPLT. ZIP--d: \SHAREA\ IMG\LCU--CAS* . *-------- 




















Note: PKUNZIP2 is available in the d: SHAREA IMG MPTS IBMCOM 
subdirectory. 


Loading the SRVIFS Utility to the Code Server 


The following is necessary for LCU. only. 


Unzip the file named SRVIFS.ZIP from the third MPTS Diskette. 








--PKUNZIP2A:\SRVIFS\SRVIFS.ZIP--d: \SHAREA\ IMG\ SRVIFS------------------: 
































Loading NetView DM/2 Extended Package to the Code Server 


This is necessary for NetView DM/2 only. 
This procedure includes transferring the DOS CC Client. 


Insert the first product diskette in drive A: and invoke: 








--A:\NVDMCOPYAT: d: \SHAREA\ IMG\NVDM2ADXISCLT- — - - - 7 - 

















Insert product diskettes 1 to 18 as prompted. 


Note: If the target directory already exists, you will be prompted to delete it. Do 
so by pressing the Enter key. 


Loading IBM PC DOS 6.3 to the Code Server 


The following steps are necessary for NetView DM/2 only: 


1. Open a virtual DOS full-screen session. Insert the first product diskette of 
IBM PC DOS 6.3 into drive A: and issue the transfer command to copy the 
DOS code to the code server. 


--A: \SETUP/A---------------------------------------------------- 








At the LAN Server Administrator Installation Option screen, change the 
target directory to d: SHAREA IMG IBMDOS63. All files are being expanded 
while transferring. 


2. Copy the files from the IBM PC DOS 6.3 CID Install Utility to the same 
directory as the one used in the step before. These files are: 
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USETUP.COM 
USETUP1.OVL 
USETUP2 .OVL 
USETUP.IN 
DOSDISK.COM 
DOSDISK.IN 















































Note to IBM employees 


IBM PC DOS 6.3 CID Install Utility can be obtained from the PCTOOLS 
disk and can be given to customers. The package name is DOSCID63. 








Loading DOS LAN Support Program 1.36 to the Code Server 


This is necessary for NetView DM/2 only. 


The diskette of DOS LAN Support Program 1.36 will be copied to the code server 
by using the XCOPY command. 


To transfer DOS LAN Support Program 1.36 onto the code server set the current 
directory to d: SHAREA IMG LSP136 and invoke the OS/2 XCOPY command: 


~-XCOPY-A: --d: --/E--/S------------------- ~------------------------ 








Loading DOS LAN Services to the Code Server 


This is necessary for NetView DM/2 only. 


The product diskettes of DOS LAN Services will be copied to the code server by 
using the XCOPY command. 


To transfer DOS LAN Services onto the code server, set the current directory to 
d: SHAREA IMG DLS and invoke the OS/2 XCOPY command as many times as 
there are product diskettes. 


-~-XCOPY-A: --d:--/E--/S----------------------------------------------- 











Selecting Network Protocols for Remote Installation 
This is necessary for NetView DM/2 and LCU. 


Using the workstation as a CID code server, you have to enable it by installing 
MPTS with the NetBIOS network protocol driver. NetBIOS is used as the 
transport protocol, and, NetView DM/2 uses the IBM IEEE 802.2 protocol to 
communicate with the clients. 


When using NetView Distribution Manager/2 2.10 in TCP/IP environments, you 
need to put NetBIOS over TCP/IP protocol. This can be easily done with 
Multiprotocol Transport Services since this product comes with the TCPBEUI 
protocol. 


1. If OS/2 LAN Server 4.0 has not been installed yet, you need to install MPTS 
on your workstation. If so, invoke the installation command; otherwise, 
double-click your MPTS icon on your Desktop. 








--d: \SHAREA\IMG\MPTS\INSTALL- - - ata a care oa - - 
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After the installation process, select Configure to customize MPTS. 


2. Your network adapter usually is detected automatically so that you only have 


to select the network protocols needed. The configuration panel of MPTS is 
shown in Figure 228. 





Select a network adapter and then select protocols to go with it. 
Network Adapters ee 
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To edit driver parameters, select an item below and 
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Figure 228. MPTS-LAPS Configuration Panel 


Note: You need to select NetBIOS protocol to work with SRVIFS, LCU, and 
IBM IEEE 802.2 for NetView DM/2. 


3. Customize NetBIOS now. 


Double-click the NetBIOS protocol driver in the Current Configuration 
container to edit the NetBIOS profile. Increase your current resource 
requirements as shown in Table 23. 























Table 23. NetBIOS Resources 
Resource Name Increase Value for NVDM/2 by Increase Value for LCU by 
Maximum Link stations Maximum number of CC Clients Number of MaxClients 
+2 
Maximum sessions Maximum number of CC Clients Number of MaxClients 
+2 
Maximum names 7 1 
Maximum commands 29 + MaxRequests (Number of LAN adapters used 
by server) * (Number of 
ClientWorkers) + 10 











Note: For looking up your NetView Distribution Manager/2 2.10 definitions, 


see Figure 230 on page 385. For looking up your SRVIFS definitions, see 
Figure 229 on page 382. 


Finish your configuration of MPTS by selecting OK. 


4. If NetBIOS and/or IBM IEEE 802.2 protocol has just been selected reboot your 
workstation to activate the new protocols and continue with the next step. 
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Adding Network Adapters to MPTS 


The following steps are necessary for NetView DM/2 and LCU. 


If you use LAN adapters that are not supported by standard MPTS, you can add 


them by doing the following steps: 


1. 


Have the NDIS device driver available for your LAN Adapter. In an OS/2 


environment, you need to have the .NIF and the .OS2 files. Usually, these 


files come with your LAN adapter. If not, contact your dealer to get the 
correct LAN adapter's NDIS device driver for OS/2. 


. On the code server, set the current directory to 


d: SHAREA IMG MPTS IBMCOM MACS, and unpack the file MACS.ZIP. 
--PKUNZIP2MACS. ZIP 








the file MACS.ZIP 





--PKZIP2MACS.ZI] 


subdirectory. 


Note: If you do not have PKZIP2 or PKZIP available, you may contact your 








. Pack all files that reside in this subdirectory to MACS.ZIP 


. Copy your additional NDIS device driver files to this subdirectory, and erase 





EPs est 


. Erase all .NIF and .OS2 files so that MACS.ZIP is the only file in this 


IBM representative to get it. PKZIP.EXE is also found on the first DB2/2 
product diskette. If you use shareware versions of PKZIP or ZIP, make sure 
that the IBM-licensed version of PKUNZIP2 can handle the built ZIP files. 


. If your new NDIS driver comes with additional message (.MSG) files you 


need to add these files to IBMCOM.ZIP, which remains in the 
d: SHAREA IMG MPTS IBMCOM subdirectory. First, unpack IBMCOM.ZIP to 
a temporary subdirectory by issuing the following command: 





--PKUNZ 





P2t 





BMCOM. Z 








PT 





EMP - --------- 








Note: Make sure you created the TEMP subdirectory before you invoke the 
PKUNZIP2 command. 


. Copy your additional message files to the temporary subdirectory. 


8. Pack all files in the temporary subdirectory to IBMCOM.ZIP 





--PKZIP2z 








BMCOM. 21 








PP a= **, 


Kas es —_ _ — Petes 





erase the temporary subdirectory. 


Enabling the LCU Software Distribution Manager 


1. LCU uses SRVIFS as the means of redirection. You need to create an 
initialization file, named SERVICE.INI, in order to install the SRVIFS utility. 
Use an ASCII editor, and type in following lines: 


Chapter 16. OS/2 LAN Server 4.0 CID Enablement 


. Copy IBMCOM.ZIP to the d: SHAREA IMG MPTS IBMCOM subdirectory, and 
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NAME=PARIS 
GROUPNAME= 
ADAPTER=0 
MAXCLIENTS=5 
MAXFILES=200 
ENTWORKERS=10 
ATH=d: \ 
ERMITWRITE=NO 

ERCLIENT=NO 

iLTLAS=READONLY, SINGLE, IMAGES, d: \SHAREA 
sLAS=READWRITE, SINGLE, LOGFILES,d: \SHARE 





NO 



































wu Q 






























































> Put 



































Tr. 
W 

















Figure 229. Initialization File for SRVIFS Named SERVICE. INI 





The first file alias named IMAGES points to the subdirectory where all 
ClD-dependent files are stored, giving read-only access. The second file 
alias, named LOGFILES, points to the log file subdirectory, giving read and 
write access. All files except the log files only need read-only permission. 
The Code Server name in this example is PARTS. 

















For the recommended share type, the following definitions apply: 


Single - A single directory for that file type. 

PerClient = A single directory for each client for logs. 
ReadOnly - The directory is ReadOnly for any client. 
ReadWrite - The directory is ReadWrite for any client. 


Store this file as SERVICE.INI in, for example, C: SRVIFS. 


2. The next step is to install SRVIFS by invoking following command: 











--d: \SHAREA\IMG\SRVIFS\THINBRY+\SRVIFS\SERVICE. INI------ 






































--/T:C:\SRVIF9S:d: \SHAREA\IMG\SRVIFS+C: \--- 7 7 = 

















Note: In this example, SRVIFS is installed on the C: drive. You may use any 
other drive. The /TU parameter stands for the boot drive. 


This routine adds d: SRVIFS to the DPATH in the CONFIG.SYS and adds a 
statement in the STARTUP.CMD as shown below: 


START C: SRVIFS SERVICE.EXE /INI=SERVICE.IN 


















































3. Later on, to check which clients are currently logged-on to the code server, 
invoke the following command at the code server's OS/2 command prompt: 








--SERVICE-/ INI=SERVICE. INI--/S-------------------------- 



































The parameter /S stands for status. 


4. Change to the d: SHAREA IMG LCU subdirectory, and extract the necessary 
REXX files for remote installation by invoking the commands as follows: 











--GETREXX%-d: \SHAREA\ IMG\0S2V211--d: \SHARI 

















A\DLL\V211- - 








Ez 








and 











--GETBOOT<: \SHAREA\ IMG\0S2V211--d: \SHAREA\EXE\V211 - 
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Note: Replace the V211 statement by V30 when using OS/2 Warp Version 3. 


Create LCU Boot Diskettes for the Client Workstation 


For diskette-initiated workstations, you need to have client boot diskettes to start 
remote installation. To create these two diskettes, follow the next steps. 


1. Depending on the OS/2 version to be used, change either to the 
SHAREA IMG OS2V211 or SHAREA IMG OS2V30 subdirectory. 


2. Have two formatted diskettes ready, insert the first diskette in the diskette 
drive A: and issue following command: 








--SEDISK-/S:d: \SHAREA\IMG\OS2V2T IA: = = = = = 


























Insert second diskette as prompted. 


Note: Change the source subdirectory according to the OS/2 version to be 
used. 


3. Leave the second diskette in the diskette drive and invoke: 








--d: \SHAREA\ IMG\MPTS \ THINHARSHAREA \ IMG\MPAS—IBMTOK.NIF----- 





























Note: The last parameter mentioned above stands for the NDIS device 
driver (.NIF) being installed. In this example, an IBM Token-Ring Adapter is 
used. Use the overview in Table 24 on page 384 to adapt this parameter 
according to the LAN adapters you use in your network environment. 


4. Install the SRVIFS requester utility by invoking: 





























--d: \SHAREA\ IMG\SRVIFS\ THING FG +\ SHAREA\ IMG\ SRVIFSA: --------- 











-- /REQ: *P/D:X-/SRV: \\ PARIS \ IMAGES----------------------- ~ 


























--d: \SHAREA\ IMG\SRVIFS\THINS FS +\ SHAREA 














ae 





MG\SRVIFSA:--------- 














--/REQ: *P/D: Y—/SRV: \\PARIS\LOGFILES 5 SSs5-s55 























Remarks: 











THINIFS is executed twice because of the two redirected drives, X: and 

Y:, which point to the code server aliases, IMAGES and LOGFILES. Compare 
these settings with the statements in the SERVICE.INI file which is 

described in Figure 229 on page 382. 

















+ The parameter /REQ: *P prompts the user to enter the client name when 
IPLing with these prepared boot diskettes. 


5. Now, change to the code server's drive, set the current directory to 
d: SHAREA IMG LCU, and enter the LCU installation command: 





--CASINSTL/TU:A:\/CMD:X: \CLIENZB—/PL:X:\IMG\LCU; X: \DLL\V211; --- 
































--/PA:X:\IMG\LCU; X: \EXE\W2HAL2 : Y: \LOG\LCU\ SRVIFS—REQ. LOG-------- 
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Table 24. Overview of MPTS-Supported LAN Network Adapters and Their .NIF 


Drivers 

LAN Adapter 

Artisoft NodeRunner & AE-X Ethernet Adapters 

Cabletron E11 Ethernet Adapter - OS/2 

Cabletron E21 Ethernet Adapter - OS/2 

Cabletron E31 Ethernet Adapter 

3Com EtherLink III Family OS/2 

3Com 3C503 EtherLink Il Adapter 

3Com 3C523 EtherLink/MC Adapter 

Intel EtherExpress 16 Family Adapter 

IBM Token-Ring Network 16/4 Adapter II (IBM16TR.OS2) 

IBM 16/4 Busmaster EISA Adapter (IBMEITR.OS2) 

IBM LAN Adapter for Ethernet (IBMENI.OS2) 

IBM LAN Adapter/A for Ethernet (IBMENII.OS2) 

Eagle Technology EtherXpert EP2000plus Adapter 

Eagle Technology EP3210 EtherXpert Adapter 

IBM Streamer Family Adapter (IBMMPC.OS2) 

Eagle Technology NE2000plus Ethernet Adapter (Novell NE2000 compatible) 
Eagle Technology NE3210 EISA Ethernet Adapter 

IBM PC Network Il and Baseband Adapters 

IBM PC Network II/A and Baseband/A Adapters 

IBM Token-Ring Network Adapter 

IBM Compatible Token-Ring Network Adapter 

IBM PCMCIA Token-Ring Network Adapters 

IBM SMP Token-Ring Network Adapter 

IBM Token-Ring Network Busmaster Server Adapter 

IBM LANStreamer Adapter NDIS Device Driver (IBMTRDB.OS2) 
3270 Adapter for 3174 Peer Communications 

Intel TokenExpress(tm) 16/4 Adapter 

Intel TokenExpress(tm) EISA/32 Adapter 

IBM PS/2 Adapter for Ethernet Networks 

Standard Microsystems EtherCard PLUS Software-Configured Adapters 
Standard Microsystems EtherCard PLUS Micro Channel Adapters 
Olicom Token-Ring Network 16/4 Adapters 

Dowty Network Systems PC/PS-x1x4/x5 

IBM Credit Card Adapter for Ethernet with NDIS support (PCMNICCS.OS2) 
Racore 16/4 Token-Ring Adapter 

Cabletron T20 Tokenring Adapter - OS/2 

Cabletron T30 Tokenring Adapter - OS/2 

Thomas-Conrad Token Ring Adapter 


Inside OS/2 LAN Server 4.0 


-NIF Driver 
AEXNDIS.NIF 
E11.NIF 
E21.NIF 
E31.NIF 
EL3IBMO2.NIF 
ELNKII.NIF 
ELNKMC.NIF 
EXP16.NIF 
IBM160S2.NIF 
IBMEIOS2.NIF 
IBMENI.NIF 
IBMENII.NIF 
IBMEP200.NIF 
IBMEP321.NIF 
IBMMPC.NIF 
IBMNE200.NIF 
IBMNE321.NIF 
IBMNET.NIF 
IBMNETA.NIF 
IBMTOK.NIF 
IBMTOKC.NIF 
IBMTOKCS.NIF 
IBMTOKMP.NIF 
IBMTRBM.NIF 
IBMTRDB.NIF 
IBMXLN.NIF 
INTEL16.NIF 
INTEL32.NIF 
MACETH.NIF 
MACWDAT.NIF 
MACWDMC.NIF 
OLITOK.NIF 
PCO4.NIF 
PCMNICCS.NIF 
RTR16NDS.NIF 
T20.NIF 
T30.NIF 
TCCTOK.NIF 





Enabling the NetView DM/2 Software Distribution Manager 


1. Since NetView DM/2 uses DB2/2 to store all information, make sure you have 
DB2/2 installed. You must be allowed to create local databases. And you 
must be logged-on with a user ID that has SYSADM authority. Before you 
actually start to install NetView DM/2, you ought to customize the DB2/2 
Database Manager. This is to improve NVDM/2 performances. Invoke the 
following command: 


























--DBM—UPDATEDATABASE MANAGKEONFIGURATIONSING-SQLENSEG 40---- 























Stop (STOPDBM) and restart (STARTDBM) the Database Manager to make 
this change effective before you install NetView DM/2. 


Then continue as follows. 


2. Change to the code server's subdirectory d: SHAREA IMG NVDM2V21. You 
may now install NetView DM/2 interactively by using the NVDMPMS 
command or unattendedly by using the NVDMINST command, which uses a 
response file. 


If you wish to install NetView DM/2 by dialogs, change to the code server's 
subdirectory d: SHAREA IMG NVDM2V21 and issue the following command: 





--NVDMPMS - ---------------------------------------------------- 





Go through all the configuration panels, and enter the values as shown in the 
response file shown in Figure 230. 


If you want to install NetView DM/2 by command, invoke the following 
commana: 

















--NVDMINSE/R: \SHAREA\RSP\NVDM2V21\FLORIDA.RSP--- - - 














The resonse file to be used here contains following entries: 











// 

// Command line values 

// 

BootDrive =C // Drive where CONFIG.SYS will be updated 
SourceDir =d: \SHAREA\IMG\NVDM2V21 

TargetDir =d: \NVDM2V21 

LogFile =C:\0S2\INSTALL\NVDMINST. LOG 

CDM =C // Install a Stand-Alone server 
LDUDistributor =YES // Install LDU Distributor 

LDUManager =YES // Install LDU Change File Builder 














Figure 230 (Part 1 of 2). NetView DM/2 CC Server Response File 
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// 

// Configuration values 

// 

ServerName =FLORIDA // lenght max. 8 characters 
FileServiceDir =d:\FSDATA 

SharedDirA =d: \SHAREA 

SharedDirB =d: \SHAREB 

MaxShrFiles =1500 // up to 10.000 is supported 
MaxClients =10 // up to 1.000 is supported 
MaxRequests =8 // Range is from 1 to 8 
ErrorLogFile =C: \0S2\INSTALL\NVDMINST .ERR 

AdapterNum =0 // Adapter 1 is also supported 








Figure 230 (Part 2 of 2). NetView DM/2 CC Server Response File 

Using the response file shown in Figure 230 on page 385, the NVDMINST 
installation command will install a stand-alone server, a so-called CC Server, 
LDU Distributor and the LDU Manager. 


At the end of the installation, you will be prompted to reboot your workstation. 


Create Change File Profiles 


386 


Software that is supposed to be distributed must be cataloged in the CDM 
catalog. To catalog software, you need to have a change file for each software 
package to be distributed. 


For easy building of a CDM catalog, we suggest building change file profiles 
instead of going through panels to create the change files. Use an ASCII Editor, 
and create those files shown below. Store them in the code server's 
subdirectory d: SHAREA PROFILES. 


OS/2 2.11 Install Profile 
Store the contents shown below as SHAREA PROFILES OS2V211.PRO. 


TargetDir=A: \ 
Section Catalog 
Begin 
ObjectType=Software 
GlobalName=ITSCAUS .0S2V211.INST.REF.2.11 
Description="Install Procedure for OS/2 2.11" 


End 
Section Install 

Begin 
Program = SA:\EXE\V211\SEINST. EXE 
Parms = /S:$(SourceDir) /B:C: /R:$(ResponseFile) /L1:$(LogFilel) /T:$(TargetDir 
SourceDir = SA:\IMG\OS2V211 
ResponseFile = SA:\RSP\OS2V211\S$ (WorkStatName) .RSP 
LogFilel = SB: \LOG\O0S2V211\$ (WorkStatName) .LOG 

End 








Figure 231. OS/2 2.11 Install Profile for NVDM/2 


OS/2 Warp Version 3 Install Profile 
Store the contents shown below as SHAREA PROFILES OS2V30.PRO. 


Inside OS/2 LAN Server 4.0 








TargetDir=A: \ 
Section Catalog 
Begin 
ObjectType=Software 
GlobalName=ITSCAUS .OS2WARP3.INST.REF.3.0 
Description="Install Procedure for OS/2 Warp Version 3" 


End 
Section Install 

Begin 
Program = SA:\EXE\V30\SEINST.EXE 
Parms = /S:$(SourceDir) /B:C: /R:$(ResponseFile) /L1:$(LogFilel) /T:$(TargetDir) 
SourceDir = SA:\IMG\0S2V30 
ResponseFile = SA:\RSP\OS2V30\$ (WorkStatName) .RSP 
LogFilel = SB: \LOG\O0S2V30\$ (WorkStatName) . LOG 

End 


Figure 232. OS/2 Warp Version 3 Install Profile for NVDM/2 


MPTS Install Profile 
Store the contents shown below as SHAREA PROFILES MPTS.PRO. 


TargetDir=C:\ 

Section Catalog 

Begin 
ObjectType=Software 
GlobalName=ITSCAUS .MPTS.INST.REF.2.1 
Description="Install Procedure for MPTS V2.1" 


End 
Section Install 
Begin 
Program = $(SourceDir) \MPTS. EXE 
Parms = /E:MAINT /S:$(SourceDir) /T:$(TargetDir /R:$(ResponseFile) 
SourceDir = SA:\IMG\MPTS 
ResponseFile= SA:\RSP\MPTS\S$ (WorkStatName) .RSP 
LogFilel = SB:\LOG\MPTS\S$ (WorkStatName) . LOG 
End 





Figure 233. MPTS Install Profile for NVDM/2 


NVDM/2 CC OS/2 Client Install Profile 
Store the contents shown below as SHAREA PROFILES CCCOS2.PRO. 


TargetDir = C:\NVDM2V21 
Section Catalog 
Begin 
ObjectType SOFTWARE 
GlobalName = ITSCAUS.CCCOS2.INST.REF.2.1 
Description = "Install Procedure for CC OS/2 Client Feature of NvDM/2 V2.1" 
End 
Section Install 
Begin 
Program = $(SourceDir) \NVDMCLT. EXE 


SourceDir = SA:\IMG\NVDM2V21 

ResponseFile = SA:\RSP\NVDM2V21\$ (WorkStatName) .RSP 

LogFilel = SB: \LOG\NVDM2V21\$ (WorkStatName) . LOG 
End 





Parms = /B:C /S:$(SourceDir) /T:$(TargetDir) /R:$(ResponseFile) /L1:$(LogFilel1) 





/L1:$(LogFilel) /TW:$(Target 











Figure 234. CC OS/2 Client Install Profile for NVDM/2 
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OS/2 LAN Server 4.0 Requester Install Profile 
Store the contents shown below as SHAREA PROFILES LS40AREQ.PRO. 





TargetDir=C: \IBMLAN 
Section Catalog 
Begin 
ObjectType=Software 
GlobalName=ITSCAUS .LS40AREQ.INST.REF.4.0 
Description="Install Procedure for OS/2 LAN Server 4.0 - Requester 


End 
Section Install 

Begin 
Program = $(SourceDir) \LANINSTR. EXE 
Parms = /REQ /R:$(ResponseFile) /L1:$(LogFilel) /L2:$ (LogFile2) 
SourceDir = SA:\IMG\LS40A 
ResponseFile = SA:\RSP\LS40A\$ (WorkStatName) .RSP 
LogFilel = SB: \LOG\LS40A\$ (WorkStatName) .L1 
LogFile2 = SB: \LOG\LS40A\$ (WorkStatName) .L2 

End 











Figure 235. OS/2 LAN Server 4.0 Requester Install Profile for NVDM/2 


OS/2 LAN Server 4.0 Server Install Profile 
Store the contents shown below as SHAREA PROFILES LS40ASRV.PRO. 





TargetDir=C: \IBMLAN 
Section Catalog 
Begin 
ObjectType=Software 
GlobalName=ITSCAUS .LS40ASRV.INST.REF.4.0 
Description="Install Procedure for OS/2 LAN Server 4.0 - Server" 


End 
Section Install 

Begin 
Program = $(SourceDir) \LANINSTR. EXE 
Parms = /SRV /R:$(ResponseFile) /L1:$(LogFilel) /L2:$ (LogFile2) 
SourceDir = SA:\IMG\LS40A 
ResponseFile = SA:\RSP\LS40A\$ (WorkStatName) .RSP 
LogFilel = SB: \LOG\LS40A\$ (WorkStatName) .L1 
LogFile2 = SB: \LOG\LS40A\$ (WorkStatName) .L2 

End 











Figure 236. OS/2 LAN Server 4.0 Server Install Profile for NVDM/2 


IBM PC DOS 6.3 Install Profile 
Store the contents shown below as SHAREA PROFILES IBMDOS63.PRO. 





TargetDir = C:\DOS 
Section Catalog 


Begin 

ObjectType = SOFTWARE 

GlobalName = ITCSAUS.DOS.INST.REF.6.3 

Description = "Install Procedure for IBM PC DOS 6.3" 
End 











Figure 237 (Part 1 of 2). IBM PC DOS 6.3 Install Profile for NVDM/2 
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Section Install 
Begin 
Program = $(SourceDir) \USETUP.COM 
Parms = /T:$(TargetDir) /R:$(ResponseFile) /L1:$ (LogFile1) 
ResponseFile = SA:\RSP\IBMDOS63\$ (WorkStatName) .RSP 
SourceDir = SA:\IMG\IBMDOS63 


LogFilel = SB: \LOG\IBMDOS63\$ (WorkStatName) . LOG 
End 











Figure 237 (Part 2 of 2). IBM PC DOS 6.3 Install Profile for NVDM/2 


The DOS LAN Support Program Install Profile 
Store the contents shown below as SHAREA PROFILES LSP.PRO. 





TargetDir = C:\ 
Section Catalog 
Begin 
ObjectType 
GlobalName 
Description 
End 
Section Install 
Begin 
Program = $(SourceDir) \DXMAID. EXE 
Parms = /S:$(SourceDir) /TU:$(TargetDir) /R:$(ResponseFile) /L1:$(LogFilel) /X 
ResponseFile = SA:\RSP\LSP136\$ (WorkStatName) .RSP 
SourceDir = SA:\IMG\LSP136 


LogFilel = SB: \LOG\LSP136\$ (WorkStatName) . LOG 
End 


SOFTWARE 
ITCSAUS .LSP.INST.REF.1.36 
"Install Procedure for LAN Support Program V1.36" 





Figure 238. DOS LAN Support Program Install Profile for NVDM/2 


The NVDM/2 CC DOS Client Install Profile 
Store the contents shown below as SHAREA PROFILES CCCDOS.PRO. 


TargetDir = C:\ 
Section Catalog 
Begin 
ObjectType 
GlobalName 
Description 
End 
Section Install 
Begin 
Program = $(SourceDir) \NVDMIDOS. EXE 
Parms = /S:$(SourceDir) /T:$(TargetDir) /R:$(ResponseFile) /L1:$(LogFile1) 
ResponseFile = SA:\RSP\NVDM2V21\$ (WorkStatName) .RSP 
SourceDir = SA:\IMG\NVDM2V21 
LogFilel = SB: \LOG\NVDM2V21\$ (WorkStatName) . LOG 


SOFTWARE 
ITCSAUS .CCCDOS.INST.REF.2.1 
"Install Procedure for CC DOS CLient Feature of NvDM/2 v2.1" 


End 





Figure 239. CC DOS Client Install Profile for NVDM/2 


The DOS LAN Services Install Profile 
Store the contents shown below as SHAREA PROFILES DLS.PRO. 
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TargetDir = C:\ 
Section Catalog 
Begin 
ObjectType 
GlobalName 
Description 
End 
Section Install 
Begin 
Program = $(SourceDir) \INSTALL.EXE 
Parms = /R:$(ResponseFile) /L1:$(LogFilel) /L2:$ (LogFile2) 
ResponseFile = SA:\RSP\DLS\$ (WorkStatName) .RSP 
SourceDir = SA:\IMG\DLS 
LogFilel SB: \LOG\DLS\$ (WorkStatName) .ERR 
LogFile2 SB: \LOG\DLS\$ (WorkStatName) .HST 
End 


SOFTWARE 
ITCSAUS .DLS.INST.REF.4.0 
"Install Procedure for DOS LAN Services" 











Figure 240. DOS LAN Services Install Profile for NVDM/2 


Create CC Client Boot Diskettes for OS/2 


For diskette-initiated OS/2 workstations, you need to have client boot diskettes to 
start remote installation. To create these two diskettes follow the next steps. 


1. Depending on the OS/2 version to be used, change either to the 
SHAREA IMG OS2V211 or SHAREA IMG OS2V30 subdirectory. 


2. Have two formatted diskettes ready, insert the first diskette in diskette drive 
A: and issue the following command: 








--SEDISK-/S:d:\SHAREA\IMG\OS2V2T 1A: - - - - - 


























Insert second diskette as prompted. 


Note: Change the source subdirectory according to the OS/2 version to be 
used. 


3. Leave the second diskette in the diskette drive and invoke: 








--d: \SHAREA\ IMG\MPTS \THINHARSHAREA \ IMG\MPAS—IBMTOK .NIF----- 





























Note: The last parameter mentioned above stands for the NDIS device 
driver (.NIF) being installed. In this example, an IBM Token-Ring Adapter is 
used. Use the overview in Table 24 on page 384 to adapt this parameter 
according to the LAN adapters you use in your network environment. 


4. From an OS/2 window command prompt, enter the following command: 





--NVDMBDSK- - - - - = - = = 














At the Boot Diskette Update window select OS/2 as the Target Environment 
option. The name of the server used in our example is FLORIDA. Leave the 
question mark in the client's name field so that you will be prompted for the 
workstation's name after IPLing with these diskettes. 


Create CC Client Boot Diskette for DOS 


1. Before opening the virtual DOS session (full screen or window), open the 
session settings by clicking the right mouse button on the icon, selecting 
Open and then Settings. 


2. Select the Session page and open the DOS Settings. 
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3. Select DOS_VERSION setting, and add these programs to the values: 


FORMAT .CO. 




















ATTRIB. 








BX 





4. After you have added the programs, select Save. Then close the Settings 


window 


M,6,30,255 
DOSDISK.COM,6,30,255 
E,6,30,255 


5. Now, open a virtual DOS window (full screen or window), and insert a 


diskette in drive A: 


6. Change to the code server's subdirectory, d: SHAREA IMG IBMDOS63, and 
issue the following command: 





--DOS 





The diskette will be formatted. When prompted to format another diskette, 





press N. 





DISKA: --d: \SHAREA\ IMG\ IBMDOS63------------- 





7. Install LAN Support Program with NetBIOS transport system to the boot 


diskette. Issue the DXMAID command from the code server's subdirectory 


d: SHAREA IMG LSP136. 





--DXMAT 





If you are using an IBM Token-Ring Adapter, type in the highlighted values 





D== 








as shown in Figure 241. 




















Target for LSP: 
CONFIG.SYS to update: 
AUTOEXEC.BAT to update: 


Primary Adapter: ADAPT 
IBM Token-Ring Adapters (DXMCOMOD.SYS) 
Primary Adapter: PROTOCOL DRIVI 
IBM DOS NETBIOS (DXMTOMOD.SYS) 


Are you updating an existing configuration? No 
Do you have driver diskettes? 


No 


A:\ 








ER DRIVE 








A:\CONFIG.SYS 
A: \AUTOEXEC.BAT 


R 





ERS 








Figure 241. Example of a DOS LAN Support Program 1.36 Configuration for the DOS CC 
Client Boot Diskette 


8. Add NetView DM/2 DOS CC Client code to the boot diskette. To do so, issue 
the following command from an OS/2 command line: 





--NVI 


DMI 








Bl 





DSK 





At the Boot Diskette Update window select DOS as the Target Environment 
option. The name of the server used in our example is FLORIDA. Leave the 
question mark in the client's name field so that you will be prompted for the 
workstation's name after IPLing with this diskette. 
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Initiating Remote Installation with LAN CID Utility 
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This section will describe the preparation of the client specific LCU command 
files which the clients execute for remote installation. 


1. The first prerequisite is to have a file that contains the syntax of all remote 


installation commands of the software to be distributed. This general setup 
file must be created by using an ASCII editor, and in our example, it must 
contain the lines shown in Figure 242 on page 393. This file is being used 
by the CASPREFP utility which creates a client specific REXX command file for 
you. 


Table 25 shows a comparison of products and utilities and their remote 
installation commands: 





Table 25. Utilities / Programs Used in GENERAL.FIL 
































Procedure Name Remote Installation Product / Utility Name 
Command 
SEINST SEINST.EXE OS/2 V.2.11 or OS/2 Warp Version 3 
MPTS MPTS.EXE Multi-Protocol Transport Services 
LANINSTR LANINSTR.EXE OS/2 LAN Server 4.0-Requester (The /REQ 
parameter is being used) 
LANINSTS LANINSTR.EXE OS/2 LAN Server 4.0-Server (The /SRV 
parameter is being used) 
THINIFSxx THINIFS.EXE Requester part of SRVIFS (part of MPTS); xx 
represents the number of invocation 
CASINSTL CASINSTL.EXE LCU (LAN CID Utility); Part of MPTS (3rd 
diskette) 
IFSDEL IFSDEL.EXE Deletion of requester part of SRVIFS 
CASDELET CASDELET.EXE Deletion of LCU (LAN CID Utility) 








The procedure name, LANINSTS, being used in the file GENERAL.FIL 
represents the remote installation command of the server part of OS/2 LAN 
Server 4.0. 


The names of :Prog or :Utility do not have to be set equal to the name 
variable. 


-— Note OS/2 V2.11 vs. OS/2 Warp Version 3 








The GENERAL.FIL file shown in Figure 242 on page 393 only represents 
support for OS/2 V2.11. Replace following highlighted values as follows: 


OS2V211 would have been replaced with OS2V30 
v2i1 would have been replaced with vV30 








when using OS/2 Warp Version 3, or just add additional entries for OS/2 
Warp Version 3 support. If you want to add additional entries for OS/2 
Warp Version 3 support, note that LCU (CASINSTL and CASDELET) must 
also point to the IMG V30 directory. 
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/* Summary of variables referenced in the client command file being created: 
maintdir : drive letter and path from where maintenance started 
bootdrive: drive from where to boot from after first reboot 
exepath : path to the code server's executable programs subdirectory 
wkstname : reference to the workstation's name (max. 8 digits) yA 





:Prog SEINST 

Name = SEINST 

Invoke = X:\EXE\V211\SEINST /B:"bootdrive" 

/S:X:\IMG\OS2V211 /T:"maintdir" 
/U1:Y:\LOG\OS2V211\"client".LOG /R: 

Rspdir = X:\RSP\OS2V211 

Default = "wkstname".RSP 

:EndProg 




















:Prog MPTS 

Name = MPTS 

Invoke = X:\IMG\MPTS\MPTS /E:MAINT /S:X:\IMG\MPTS /G:X:\RSP\MPTS /T:"bootdrive" 
/U1:Y:\LOG\MPTS\"client".LOG /R: 

Rspdir = X:\RSP\MPTS 

default = "wkstname".RSP 

:EndProg 











:Prog LANINSTR 

Name = LANINSTR 

Invoke = X:\IMG\LS40A\LANINSTR /REQ /G:X:\RSP\LS40A 
/L1:Y:\LOG\LS40A\"client".L1 /L2:Y:\LOG\LS40A\"client".L2 /R: 

Rspdir = X:\RSP\LS40A 

Default = "wkstname".RSP 

:EndProg 











:Prog LANINSTS 

Name = LANINSTS 

Invoke = X:\IMG\LS40A\LANINSTR /SRV /G:X:\RSP\LS40A 
/L1:Y:\LOG\LS40A\"client".L1 /L2:Y:\LOG\LS40A\"client".L2 /R: 

Rspdir = X:\RSP\LS40A 

Default = "wkstname".RSP 

:EndProg 


:Utility THINIFS0O1 

Name = SRVIFS REQUESTER 01 
Invoke = X:\IMG\SRVIFS\THINIFS /S:X:\IMG\SRVIFS /T:C:\SRVIFS /TU:"bootdrive|'\ 
/L1:Y:\LOG\SRVIFS\"client".L1 /REQ:"client" /SRV:\\PARIS\IMAGES /D:x 
:EndUtility 























:Utility THINIFS02 

Name = SRVIFS REQUESTER 02 
Invoke = X:\IMG\SRVIFS\THINIFS /S:X:\IMG\SRVIFS /T:C:\SRVIFS /TU:"bootdrive|'\ 
/L1:Y:\LOG\SRVIFS\"client".L2 /REQ:"client" /SRV:\\PARIS\LOGFILES /D:y 
:EndUtility 


























:Utility CASINSTL 
Name = CASTLE 
Invoke = X:\IMG\LCU\CASINSTL /CMD:X:\CLIENT /TU: "bootdrive" /PA:X:\IMG\LCU;X: \EXE\V211 
/PL:X:\IMG\LCU;X:\DLL\V211L /L1:Y:\LOG\LCU\"client".L1 /L2:Y:\LOG\LCU\"client".L2 
:EndUtility 




















:Utility IFSDEL 

Name = IFSDEL 

Invoke = X:\IMG\SRVIFS\IFSDEL /T:C:\SRVIFS /TU:"bootdrive" 
:EndUtility 














:Utility CASDELET 

Name = CASDELET 

Invoke = X:\IMG\LCU\CASDELET /PL:X:\IMG\LCU;X:\DLL\V211; /TU:"bootdrive" 
:EndUtility 












































Figure 242. General Setup File GENERAL.FIL for LCU 


Store this file as GENERAL.FIL in the d: SHAREA CLIENT subdirectory. 
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2. The second prerequisite is to have a file that contains the installation tasks 
of the software to be distributed. This installation-dependent setup file must 
also be created by using an ASCII editor, and in our example, it must contain 
the lines shown in Figure 243 on page 394. 





:Vars 
maintdir 
bootdrive 
exepath 
wkstname 
:EndVars 


A:\ 
Cc: 

DG 
I 








\EXE\V211 
TSCWKO1 








:Install Keywords 
SEINST+MPTS+THINIFS01+THINIFS02+CASINSTL 
LANINSTR 
IFSDEL+CASDELET 
:EndiInstall 





























Figure 243. Installation Dependent Setup File ALL.FIL for LCU 


Note: Change the exepath statement to X:\EXE\V30 when using OS/2 Warp 
Version 3. 


Store this file as ALL.FIL in the d: SHAREA CLIENT subdirectory. The 
meaning of having several installation commands in a single line is that the 
products are to be installed all at once and that a reboot will be executed 
after the last installation command of the line. Just one installation 
command in a line means that a reboot of the workstation will be executed 
right after the installation of the product. 


Note: If you do not want a remotely installed product mentioned here, just 
delete the installation task or add installation tasks if you want to 
install additional products. 


3. Create the client specific command file. 


The easiest way to create the client specific command file is to use the 
CASPREFP utility which comes with LCU. In the following example, the client 
command file ITSCWK01.CMD is being created. 


a. Set the current directory to d: SHAREA CLIENT. Copy both files, ALL.FIL 
and GENERALL.FIL, to one file, TEMP.FIL, by invoking the OS/2 copy 
command: 








--COPY-ALL.FIL-- + --GENERAL.FIL--TEMP.FIL--------- - ----- 























b. Set the current directory to d: SHAREA IMG LCU. Create the client 
specific LCU command file by using the CASPREP command: 





--CASPREP-d: \SHAREA\CLIENT\TEMP.FIL--- ---- 
































--d: \SHAREA\CLIENT\ITSCWKO01.CMD--CASBASE. FIL--- = = 



































Now you are ready to start the remote installation process. Boot your 
pristine client with your LCU Boot Diskettes, and enter the client name when 
prompted. 
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Some rules about naming conventions: 


The name of the client command file is set to be equal to the client name 
prompted when booting with the ClD-prepared boot diskettes. 


The response file names have to be named equally to the client names. For 
example, if the workstation's name is ITSCWKO1, each product specific client 
response file as well as the client command file should have the file name 
ITSCWKO1. 





Initiating Remote Installation with NetView DM/2 


Before we actually can initiate remote installations with NetView DM/2, we will 
have to create a CDM catalog. Remember when you created the profiles in 
section “Create Change File Profiles” on page 386? These profiles are the basis 
for creating the CDM catalog. 


The software catalog (CDM catalog) can be created by using the CDM command. 
Issue the following commands: 































































































CDM BUILD 0S2V211.PRO FS:0S2V211.CHG 
CDM BUILD O0S2V30.PRO FS:0S2V30.CHG 
CDM BUILD MPTS.PRO FS:MPTS.CHG 

CDM BUILD CCCOS2.PRO FS:CCCOS2 .CHG 
CDM BUILD LS40AREQ.PRO FS:LS40AREQ.CHG 
CDM BUILD LS40ASRV.PRO FS:LS40ASRV.CHG 
CDM BUILD IBMDOS63.PRO FS:IBMDOS63.CHG 
CDM BUILD LSP.PRO FS:LSP.CHG 

CDM BUILD CCCDOS.PRO FS:CCCDOS.CHG 
CDM BUILD DLS.PRO FS:DLS.CHG 



































While cataloging the software, you will receive responses such as: 








[D: SHAREA PROFILES]CDM BUILD IBMDOS63.PRO FS:IBMDOS63.CHG 

BUILD was successful and an entry with Global Name 'ITCSAUS.DOS.INST.REIE 
was created in the Catalog; 
the Change File contains only the INSTALL section. 




























































































Since the software we are cataloging is ClD-enabled, the change file can only 
have the INSTALL section. 


Start NetView DM/2 by double-clicking on the CDM Dialogs icon which is in the 
NetView Applications folder. The catalog you created in the step before will now 
be shown in the CDM Catalog window. The NetView DM/2 application windows 
are shown in Figure 244 on page 396. 
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Figure 244. NetView DM/2 Application Windows 


New workstations have to be defined in the CDM CC Domain window. You can 
open this window by selecting CC Domain in the pulldown menu of the Windows 
menu item on the menu bar. 


At the CDM CC Domain window, select Workstation from the menu bar, then 
New.... You will get the New Workstation window. This window is shown in 
Figure 245. 





Node Name ITSCWKO4 





Description 


ATSC: Workstation Vivian 





Figure 245. NetView DM/2 CC Domain - New Workstation Window 


You will have to select the type of operating system the workstation is going to 
use or is using. Select OS/2 or DOS. 
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Selecting Software for Remote Installation 
1. First of all, you have to get your remote workstation ready for remote 
installation either via the prepared CC Client Boot Diskettes or via the CC 
Client feature, which in this case already is installed on the client 
workstation. If so, make sure that CDM Agent is started by entering the 
commana: 


CDM STATUS 


CDM Agent will be started with the command: 





CDM START 


2. To distribute software, select the software being distributed by clicking on 
the product's name in the CDM Catalog window. For example, select: 


a. OS/2 Software 


* OS2V211 / OS2V30 OS/2 2.11 / OS/2 Warp Version 3 
MPTS Multiprotocol Transport Services 

* CCCOS2 NVDM/2 CC OS/2 Client 
LS40AREQ OS/2 LAN Server 4.0-Requester 

b. DOS Software 

DOS IBM PC DOS 6.3 

* LSP DOS LAN Support Program 1.36 

* CCCDOS NVDM/2 CC DOS Client 

+ DLS DOS LAN Services 


Note: While selecting software, you must know the prerequisites for a 
product. For example, the OS/2 LAN Server 4.0 product can only be 
installed when Presentation Manager (Workplace Shell) is available. 
Therefore, it is not possible to install OS/2 2.11 and OS/2 LAN Server 
4.0 alla t once. In our example, we will show you how to install OS/2 
Warp Version 3, MPTS and NVDM/2 CC OS/2 Client all at once. 


3. Select Selected. From the pulldown menu select Install... 


You will get the Install window shown in Figure 246 on page 398. 
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Figure 246. NetView DM/2 Install Window 








4. Select all Objects and then select Order... to rebuild install order. You will 
get the Install Order window. Move the objects in the correct order as 
shown in Figure 247. 
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Figure 247. NetView DM/2 Install Order Window 


When done select OK. 


5. In the workstation's container, select the workstations which are supposed to 
receive the software selected. 


6. Select Options... now. Since we want NetView DM/2 to install the selected 
software all at once without rebooting the workstation after each installation 
process, you must select Install as a corequisite group as shown in 
Figure 248 on page 399. 
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Figure 248. NetView DM/2 Options Window 


When done select Set. 


. Select Install now to start the installation process. If you don't want NetView 
DM/2 to install immediately, select Schedule... to change the Preference 
option from Immediate to Deferred. 


. Select OK to close the information windows which will appear after having 
selected the Install button. 


NetView DM/2 restarts the workstation after the last installation process. 


. You may now select LS40AREQ to install OS/2 LAN Server 4.0-Requester 
since PM is available now. 


Note: You don't have to wait for the last installation process to select other 
software to be distributed to the workstation. You can do so right 
after the first installation task. 


Creating Product Specific Response Files 


Th 


is section will describe how to create product specific response files. Each 


product from IBM comes with utilities that create response files for you. 


Note: In this section, the OS/2 client's name is always ITSCWK01. The DOS 


client's name is ITSCWKO5. 


Definition of a Res 


ponse File 


A response file is an ASCII file that supplies the client-specific configuration 
information required during redirected installation of a product on the client. 
The response file contains predefined answers to the configuration questions 
that users are normally asked during a product installation. 


A response file contains pairs of keywords and values that are interpreted 
during a product installation. Usually, these keyword=value pairs are 
unique to a particular product. 


Not all products support the use of a response file. If the product you are 
installing does, the response file makes it unnecessary for you to sit at each 
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client and manually enter an answer to each question that is displayed 
during installation. 


A response file is not invoked directly. Instead, a response file is specified as 
a parameter value for an installation program. The installation command 
can be defined in the LAN CID Utility REXX command file or in the change 
profile for NetView Distribution Manager/2 2.10 The response file directs the 
processing of the installation for a particular product. 


* Comments are indicated with an asterisk. Any line beginning with this 
character will be ignored. Blank lines as well. 


* Statements do not have to start in the first column. 
Response file statements are not case sensitive. 
« Naming conventions: 


- The response file always should be named the same as the client's 
workstation name. For example: 


- The workstation's name is: ITSCWKO1 
- The response file should also be named ITSCWK01.RSP 


Note: Exception: If you want to use default response files that do not 
differ from other clients, an OS/2 response file for instance, 
then the response file can be unique to all clients. 


- Follow this rule through every product specific response file. Response 
files are stored in their product specific subdirectories on the code 
server. See the directory discussion in Figure 212 on page 362. 


OS/2 2.11 Response File 


To get the sample response file for OS/2 2.11, invoke the following command: 











--UNPACK-d: \SHAREA\ IMG\0S2V211\DISK—7 \REGUILBHAREA\RSP\OS2V211----- 


























--/N:SAMPLE.RSP-- = - = a = Sees oes 2 = 2 





Also, copy the file PRDESC.LST from the d: SHAREA IMG OS2V211 PMDD_1 
subdirectory to the OS/2 response file subdirectory, and name the file 
PRINTER.LST. 


Copy the file SAMPLE.RSP to, for example, ITSCWKO1.RSP and adapt the 
keyword=value pairs to your needs. While adapting, consider the table shown 
in Table 26. 





Table 26 (Page 1 of 2). OS/2 Keyword=Value Considerations 











Keyword Default Value Suggested Comment 
Value 
BaseFileSystem | 1 1 Set this value to 2 if you want to use 
FAT. 
DefaultPrinter 7 ze Edit file PRINTER.LST and notice line 


number of the desired printer. The line 
number is equal to the DefaultPrinter 
number. 





DiagnosticAids 1 1 Leave this value as it is since FFST/2 
needs diagnostic aids, and therefore, all 
other products like LAN Server, DB2/2, 
CM/2 and so forth do also. 














400 inside OS/2 LAN Server 4.0 





Table 26 (Page 2 of 2). OS/2 Keyword=Value Considerations 


Keyword Default Value Suggested Comment 
Value 
ExitOnError 0 This setting is required so that the SDM 
can get control after the installation is 
completed. 
Fonts 1 Leave this setting as it is, especially if 


you plan to use CM/2 on the workstation. 


FormatPartition 0 Set this value to 0 only if you want to 


migrate the operating system. 


RebootRequired | 0 This setting is required so that the 
Software Distribution Manager reboots 
the workstation instead of the SEINST 


program. 


REXX 1 LCU requires this setting. REXX is 
required whenever you want to execute 
REXX commands, whether remotely or 


locally. 








The OS/2 2.11 response file we used in our scenarios is shown in Figure 249. 


AlternateAdapter=0 

APM=0 

BaseFileSystem=1 

CDROM= 

SCSI=1 

ConfigSysLine=SET RestartObjects=StartupFoldersOnly 
ConfigSysLine=PauseOnError=NO 
CountryCode=001 
CountryKeyboard=US 
DefaultPrinter=115 
DiagnosticAids=1 
DisplayAdapter=0 
Documentation=1 

DOSSupport=1 
WIN-OS/2Support=1 

DPMI=1 

ExitOnError=1 

Fonts=1 
FormatPartition=1 
MigrateApplications=C:,C:\0S2\INSTALL\DATABASE. DAT 
MigrateConfigFiles=0 
MoreBitmaps=1 

Mouse=1 

MousePort=0 
OptionalFileSystem=1 
OptionalSystemUtilities=1 
PCMCIA=1 

PrimaryCodePage=1 
PrinterPort=1 
ProcessEnvironment=1 
ProgressIndication=1 
RebootRequired=0 

REXX=1 

SerialDeviceSupport=1 
ToolsAndGames=1 
































Figure 249. Response File for the OS/2 2.11 Base System Installation 
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MPTS Response File 


In order to get a complete MPTS response file, you may use the LAPSRSP utility, 
which extracts the settings of a current installation. 


402 


Note: The LAPSRSP utility is not able to extract TCP/IP configuration settings. 





--d: \SHAREA\IMG\MPTS \LAPSRSPEBMCOM\ PROTOCOL. 
--d: \SHARI 














EA\RSP\MPTS\1 





[TSCWKG1/IRGR—/ I: PRODUCTAU : NI 











N = = 

















eI 
= 





Or, you may use and adapt sample response files that are delivered in the 
SAMPLES directory on the third MPTS diskette. Insert the diskette in drive A:, 
and issue following command from an OS/2 command line: 


—-PKUNZIP2A: \SAMPLES \SAMPL 























ES -dERSHAREA\RSP\MPTS\SAMPLI 


The following sample response file configures an IBM Token-Ring Network 
adapter driver that binds to the IBM IEEE 802.2 and NetBIOS protocol drivers. 











INST_SECTION = ( 

















TARGET = C: 
INSTALL = PRODUCT 
UPGRADE_LEVEL = NEW 
) 
PROTOCOL = ( 
PROT_MAN] 








IBMLXCFG] 







































































DRIVERNAME = PROTMANS 


LANDD_nif = LANDD.nif 
NETBEUI_nif = NETBEUI.nif 


IBMTOK_nif = IBMTOK.nif 
NETBIOS] 

DriverName = netbios$ 

ADAPTERO = netbeuiS,0 
LANDD_nif 

DriverName = LANDDS 

Bindings = IBMTOK_nif 

ETHERAND_TYPE = "I" 

SYSTEM_KEY = 0x0 

OPEN_OPTIONS = 0x2000 

TRACE = 0x0 

LINKS = 8 

MAX_SAPS = 6 

MAX _G_SAPS = 0 

USERS = 6 

TI_TICK_G1 = 255 

T1_TICK_G1 = 15 

T2_TICK_G1 = 3 

TI_TICK_G2 = 255 

T1_TICK_G2 = 25 

T2_TICK_G2 = 10 

IPACKETS = 250 

UIPACKETS = 100 

MAXTRANSMITS = 6 

MINTRANSMITS = 2 

TCBS = 64 

GDTS = 30 

ELEMENTS = 1200 








Figure 250 (Part 1 of 2). MPTS Response File: IBM IEEE 802.2 and NetBIOS Protocol 


Drivers 
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[NETBEUI_nif] 
DriverName = netbeuiS$ 
Bindings = IBMTOK_nif 
ETHERAND_TYPE = "I" 
USEADDRREV = "YES" 
OS2TRACEMASK = 0x0 
SESSIONS = 130 
NCBS = 225 
NAMES = 21 
SELECTORS = 15 
USEMAXDATAGRAM = "NO" 
ADAPTRATE = 1000 
WINDOWERRORS = 0 
MAXDATARCV = 4168 
TI = 30000 
TL = 1000 
TZ = 200 
MAXIN = 1 
MAXOUT = 1 
NETBIOSTIMEOUT = 500 
NETBIOSRETRIES = 2 
NAMECACHE = 1000 

RNDOPTION = 0 

PIGGYBACKACKS = 1 

DATAGRAMPACKETS = 

PACKETS = 350 

LOOPPACKETS = 8 

PIPELINE = 5 

MAXTRANSMITS = 6 

MINTRANSMITS = 2 

DLCRETRIES = 10 

FCPRIORITY = 5 

NETFLAGS = 0x0 

[IBMTOK_nif] 

DriverName = IBMTOKS 

ADAPTER = "PRIMARY" 

NETADDRESS = "4000638700AB" 

MAXTRANSMITS = 6 

RECVBUFS = 2 

RECVBUFSIZE = 256 

XMITBUFS = 1 

) 






























































10 


nN 



























































Figure 250 (Part 2 of 2). MPTS Response File: IBM IEEE 802.2 and NetBIOS Protocol 
Drivers 


Note: If you are using a locally administered address, adapt the NETADDRESS 
statement. Otherwise, delete the line. 


The following sample response file configures an IBM Token-Ring Network 
adapter driver bound to the TCP/IP, TCPBEUI and NETBIOS protocol drivers. 
NETBEUI is configured for logical adapter 0, and TCPBEUI is configured for 
logical adapter 1. 


INST_SECTION = 
UPGRADE_LEV: 























TARGET = C: 
INSTALL = PRODUCT 
) 








Figure 251 (Part 1 of 3). MPTS Response File: TCP/IP, TCPBEUI and Native NetBIOS 
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PROTOCOL = ( 




















[PROT_MAN 

DRIVERNAME = PROTMANS 
[IBMLXCFG] 

NETBEUI_nif = NETBEUI.nif 





TCPBEUI_nif = TCPBEUI.nif 
TCPIP_nif = TCPIP.nif 
IBMTOK_nif = IBMTOK.nif 
[NETBIOS] 
DriverName = netbios$ 
ADAPTERO = netbeuiS,0 
ADAPTER1 = tcpbeui$,1 





























DriverName = netbeui$ 
Bindings = IBMTOK_nif 
ETHERAND_TYPE = "I" 
USEADDRREV = "YES" 
OS2TRACEMASK = 0x0 
SESSIONS = 130 

NCBS = 225 

NAMES = 21 

SELECTORS = 15 
USEMAXDATAGRAM = "NO" 
ADAPTRATE = 1000 
WINDOWERRORS = 0 
MAXDATARCV = 4168 

TI = 30000 

T1 = 1000 

T2 = 200 
MAXIN = 1 
MAXOUT = 1 
NETBIOSTIMEOUT = 500 
NETBIOSRETRIES = 2 
NAMECACHE = 1000 
RNDOPTION = 0 
PIGGYBACKACKS = 
DATAGRAMPACKET 
PACKETS = 350 
LOOPPACKETS = 8 
PIPELINE = 5 























Bd ad 






































n 
We 




















6 
MINTRANSMITS = 2 
DLCRETRIES = 10 
FCPRIORITY = 5 
NETFLAGS = 0x0 
[TCPBEUI_nif] 
DriverName = tcpbeuiS 
Bindings = , IBMTOK_nif 
OS2TRACEMASK = 0x0 
SESSIONS = 40 
NCBS = 95 
NAMES = 21 
SELECTORS = 5 
USEMAXDATAGRAM = "NO" 
NETBIOSTIMEOUT 500 
NETBIOSRE IES = 2 
NAMECACHE 0 
PRELOADCACHE = "NO" 
NAMESFILE 0 
DATAGRAMPACKETS = 20 
PACKETS = 50 























I 




















R 
H 



































Figure 251 (Part 2 of 3). MPTS Response File: TCP/IP, TCPBEUI and Native NetBIOS 
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[TCPIP_nif] 

DriverName = TCPIPS 
Bindings = IBMTOK_nif 
[IBMTOK_nif] 

DriverName = IBMTOKS 
ADAPTER = "PRIMARY" 
MAXTRANSMITS = 6 
RECVBUFS = 2 
RECVBUFSIZE = 256 
XMITBUFS = 1 











) 








MPTS = ( 

[CONTROL ] 
Local_IPC = YES 
INET_Access = YES 





NETBIOS_Access = NO 
[IFCONFIG] 
Interface 
Address 
Brdcast 
Dest 
Enable 
Netmask 
Metric 
Mtu 
Trailers 
Arp 
Bridge 
Snap 
Allrs 
802.3 
Icmpred 
Canonical 
[ROUTE] 
Type 
Action 
Dest 
Router 
Metric 


) 


No 
N 
N 
N 


OwGd 
Cae 
w 
w 
w 


BR 





NHoO 
no 


K 
ci Ku 


GI 
n 





Hm 
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default 
add 


4.4.4.4 
1 











Figure 251 (Part 3 of 3). MPTS Response File: TCP/IP, TCPBEUI and Native NetBIOS 


NVDM/2 CC OS/2 Client Response File 


There are sample response files for NVDM/2 CC OS/2 Client installation on the 
last diskette of NetView DM/2, labeled Documentation Samples. Only two 
keywords are necessary to mention. In our test environment, we used the 
NVDM/2 CC OS/2 Client response file shown in Figure 252. 





ServerName=FLORIDA 
ClientName=ITSCWK01 











Figure 252. Response File for the NVDM/2 CC OS/2 Client Installation 


OS/2 LAN Server 4.0 Response File 


Use the LANINSTR command to create an OS/2 LAN Server 4.0 response file for 
a requester or a server. Change to the code server's subdirectory 
d: SHAREA IMG LS40A and invoke: 


--LANINSTR/7 SRV- - = - - = = - 
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Go the tailored installation/configuration path. Depending on the type of client, 
select Create Requester response file for remote installation or Create Server 

response file for remote installation. Go through all panels as you would when 
installing the workstation itself. 


Note: If you want the target workstation to be migrated from a previous release, 
you will just have to select: Use target settings. 


The response file shown in Figure 253 is intended for a remote installation of an 
OS/2 LAN Server 4.0-Requester. 














DELETEIBMLAN = Networks< 
net2 = 
net3 
net4 = 
netlb = 





UPDATEIBMLAN = Networks< 
netl = NETBEUIS,*,LM10,*,*,* 














DELETEIBMLAN = Peer< 
srvnets = NETLB,NET2,NET3,NET4 























UPDATEIBMLAN 
security = 
srvnets = N 


Peer< 
igrate 


= 


As 








DELETEIBMLAN = Requester< 
wrknets = NETLB,NET2,NET3,NET4 






































UPDATEIBMLAN = Requester< 
Computername = ITSCWKO1 
Domain = HIGHLIGHTS94 
useallmem = No 
wrknets = NET1 

> 

ADDIBMLAN = Requester< 
wrkservices = MESSENGER 

> 



































Figure 253 (Part 1 of 2). Response File for the OS/2 LAN Server 4.0 - Requester 
Installation 
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ConfigApplDumpPath = C:\0S2\SYST 
ConfigApplMaxDumps = 32 
ConfigAutoStartFFST = No 
ConfigAutoStartLsS = Yes 
ConfigDisplayMSG = ON 
ConfigDosNumber = 0 
ConfigMsgLogName = C:\0S2\SYSTEM\OS2MLOG. DAT 
ConfigSourceDrive = None 
ConfigSystemDumpPath = C:\0S2\SYST 
ConfigSystemMaxDumps = 32 
ConfigTargetDrive =C 
ConfigWsId = ITSCWKO1 
ConfigWsSeriall = 23 
ConfigWsSerial2 = 0030462 
ConfigWsTypel = 8580 
ConfigWStype2 = X21 

InstallAPI = INSTALLIFREQUIRED 
InstallDosLanApi = INSTALLIFREQUIRED 
InstallFFST = INSTALLIFREQUIRED 
InstalliInstallProgram = INSTALLIFREQUIRED 
InstallPeerService = INSTALLIFREQUIRED 
InstallRemoteFaultTolerance = INSTALLIFREQUIRED 
InstallRequester = INSTALLIFREQUIRED 
InstallUPM = INSTALLIFREQUIRED 
InstallMSGPopup = INSTALLIFREQUIRED 
InstallGUI = INSTALLIFREQUIRED 
InstallClipBoard = INSTALLIFREQUIRED 
InstallDesktopIcons = YES 
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Figure 253 (Part 2 of 2). Response File for the OS/2 LAN Server 4.0 - Requester 
Installation 


IBM PC DOS 6.3 Response File 


On the IBM PC DOS 6.3 CID Install Utility diskette, you will find a sample 
response file for installing IBM PC DOS 6.3 remotely. Adapt the values of the 
keywords to your needs. The response file we used in our test environment is 
shown in Figure 254. 





AntiVirus=Y 

AntiVirus forWindows=N 
Compression=N 
CountryCode=35 
CountryKeyboard=38 
CPBackup=Y 
CPBackupforWindows=N 
CPUndeleteforWindows=N 
DOSSHELL=Y 
ExitIfCompression=N 
ISOFonts=Y 

PCMCIA=N 

PenDOS=N 

* PreviousDOSPath=C: \DOS 
ProgressIndication=Y 
TargetPath=C:\DOS 

* WindowsPath=C: \WINDOWS 








Figure 254. Response File for the IBM PC DOS 6.3 Installation 
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DOS LAN Support Program 1.36 Response File 


For a description of the DOS LAN Support Program 1.36 response file, consult 
the README files provided on the DOS LAN Support Program 1.36 diskette. The 
two files are: READCID.ccc and READINFO.ccc, where ccc represents the country 
code. There are sample response files for different configurations provided in 

the SAMPLES directory on the diskette. In our test environment, we used the 
DOS LAN Support Program 1.36 response file shown in Figure 255. 





* This response file installs IBM IEEE 802.2 and NetBIOS support 
INST_SECTION = ( 
MigrateControlFiles = 0 
AdapterCheck = 0 
TargetPath = C:\NET 
) 
PROT_SECTION = ( 
DriverName = DXMCOMODS 
lsp_primary = 1 
NetAddress = "400063840001" 
MinLink = 2 
MinSAP = 12 
) 
PROT_SECTION = ( 
DriverName = DXMTOMODS 
lsp_primary = 1 


























c=14 
st = 14 
s=14 
es =2 
est = 2 
cf=y 
PBA = 0 


) 











Figure 255. Response File for the DOS LAN Support Program 1.36 Installation 


NVDM/2 CC DOS Client Response File 


There are sample response files for NVDM/2 CC DOS Client installation on the 
last diskette of NetView DM/2 labeled "Documentation Samples". Only two 
keywords are necessary to mention. In our test environment, we used the DOS 
LAN Support Program 1.36 response file shown in Figure 256. 





ServerName=FLORIDA 
ClientName=ITSCWKO05 











Figure 256. Response File for the NVDM/2 CC DOS Client Installation 


DOS LAN Services Response File 


There is a sample response file for DOS LAN Services installation on the first 
diskette of DOS LAN Services. In our test environment, we used the DOS LAN 
Services response file shown in Figure 257 on page 409. 
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[dlsmain] 
computername=ITSCWK05 
domainname=ANYDOM01 
username=TAYLOR 
configsys=C: 
autoexecbat=C: 
target=C: \NET 
peer=yes 
redirecter=full 
windowsupport=yes 
ddeclipboard=yes 
gui=yes 
install_802=yes 
startupopt=logon 





[dlsdriver] 
ncbs=30 
sessions=33 








Figure 257. Response File for the DOS LAN Services Installation 


-— Important for NetView DM/2 
DOS CC Client only works properly with DOS LAN Support Program loaded. 


yes. Otherwise, the DOS workstation will not be able to load CC Client. 





Therefore, you need to include the instal1_802 keyword and set its value to 
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Chapter 17. LAN Virtual Device Driver Support 


This chapter will describe how to set up an OS/2 V2.11 workstation virtually with 
LAN device drivers so that a (Multiple) Virtual DOS Machine (MVDM) session 
under OS/2 V2.11 behaves like a native DOS machine. Three different virtual 
device drivers are available and discussed here: 


NetBIOS LAN VDD provided by Multiprotocol Transport Services 
IBM IEEE 802.2 LAN VDD provided by Multiprotocol Transport Services 
DOS LAN Services API VDD provided by OS/2 LAN Server 4.0 


The NetBIOS and IBM IEEE 802.2 LAN virtual device driver (LAN VDD) supplied 
with MPTS-LAPS enables DOS NetBIOS and DOS IBM IEEE 802.2 applications to 
share network adapters with OS/2 NetBIOS and OS/2 IBM IEEE 802.2 
applications. 


Windows NetBIOS and Windows IBM IEEE 802.2 applications can also use the 
LAN VDD. 


The virtual DOS LAN API Support enables DOS applications that are running in a 
specific version of DOS on OS/2 to call LAN APIs without requiring the 
installation of DOS LAN Services. Virtual DOS LAN API support is a component 
of OS/2 LAN Server 4.0 


Using the LAN virtual device drivers, you can set up a MVDM, for example, for 
Personal Communications/3270 over token-ring, another MVDM for DOS LAN 
Services, another MVDM for DOS LAN Requester, and so forth. 


Above all, you can enable your WIN-OS/2 environment for networking so that you 
can use all kinds of network resources like multiple LAN printers. 


Installing the LAN Virtual Device Driver 


MPTS-LAPS provides adapter, NetBIOS protocol, LAN Virtual Device Driver 

(VDD) and IBM IEEE 802.2 support. If you install LAN adapter support bound to 
IBM OS/2 NetBIOS and IBM IBM IEEE 802.2, MPTS automatically installs the LAN 
VDD files. LAN VDD support is enabled by two device driver statements in the 
CONFIG.SYS file: 


DEVICE=C: IBMCOM PROTOCOL LANPDD.OS2 
DEVICE=C: \ IBMCOM\ PROTOCOL\LANVDD.OS2 
























































assuming that MPTS is installed on the C: drive. 
Note: If you do not need VDD support, you can remove these two statements 
from the CONFIG.SYS file. 


Add the following statement in the CONFIG.SYS file if you are using a network 
application that requires a specific version of DOS to be started from OS/2 V2.11: 





DEVICE=C: IBMCOM PROTOCOL LANVMEM.SYS 


























by doing the following steps: 
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1. Virtual DOS machine 


a. Open the session settings of the virtual DOS machine by clicking the 
right mouse button on the icon, selecting Open and then Settings. 


b. Select the Session page and open the DOS settings. 


c. Select DOS_DEVICE setting and add the above mentioned statement to 
the Values. 


d. After you have added the statement, select Save. Then close the 
Settings window. 


2. Place the above mentioned statement in the CONFIG.SYS file of the DOS 
boot location that is specified by the DOS_STARTUP_DRIVE parameter in 
DOS Settings for a specific DOS session. 


3. Place the above mentioned statement in the OS/2 CONFIG.SYS file to load 
the driver for all DOS sessions. 


The LANVMEM.SYS device driver for DOS allocates memory during a boot 
sequence of a MVDM. It is not required if an emulated 8086 mode MVDM is 
booted (for example when IPLing a PC DOS 6.3 MVDM). 


If you also need HLLAPI support in your OS/2 virtual machine environment, you 
need to add the following statement to your boot environment: 








DEVICE=d: CMLIB VHAPI.OS2 
































Note: VHAPI is a Communications Manager/2 feature. For more information, 
refer to the VHAPI.DOC documentation. 


Configuring the LAN Virtual Device Driver 


You must first configure the total OS/2 NetBIOS and IBM IEEE 802.2 resources 
that your workstation requires before configuring the LAN VDD. 


The LAN VDD indirectly uses the OS/2 NetBIOS and IBM IEEE 802.2 resources. 
Changing the LAN VDD parameters has no effect on the total OS/2 NetBIOS and 
IBM IEEE 802.2 resources allocated. The configuration of the LAN VDD only sets 
the number of resources a DOS NetBIOS or DOS IEEE 802.2 application can 
request for each DOS session. Each DOS session that uses the LAN VDD is 
considered a single user to LAPS, regardless of the number of LAN applications 
running in a DOS session. 


If a DOS NetBIOS application requires more than the default number of NetBIOS 
commands, sessions, and names, or requires Name Number 1 support, use the 
LTSVCFG utility program to change the defaults. This utility resides in the 
IBMCOM directory. 


If a DOS IEEE 802.2 application requires Direct Station support, you may also use 
the LTSVCFG utility to configure. If a DOS IEEE 802.2 application requires a 
group address, the System key parameter of the IBM IEEE 802.2 protocol driver 
must specify a value greater than 0. 
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LTSVCFG Utility 

LTSVCFG enables you to configure NetBIOS and IEEE 802.2 resources on a per 
DOS session basis. In most situations, the following resources support DOS 
NetBIOS and DOS IEEE 802.2 applications when the following line is added to the 
AUTOEXEC.BAT file: 


d: IBMCOM LTSVCFG S=12 C=14 N=8 N1=0 D=0 




















where d: is the drive where you installed LAPS, S is the number of sessions, C is 
the number of commands, N is the number of names, N1 is Name Number 1 
supports is not requested, and D is Direct Station support not requested. 





This command must be invoked before any DOS NetBIOS or DOS IEEE 802.2 
applications are started. 


LTSVCFG enables you to set DOS NetBIOS and DOS IEEE 802.2 parameters for 
each network adapter. Currently, support is provided for up to four network 
adapters. 


Examples: 


Request of 10 sessions, 30 commands, 14 names, Name Number 1, and 
Direct Station support for adapter 0: 


LTSVCFG S=10 C=30 N=14 N1=1 D=1 








Request of the defaults for adapter 0. Additionally 12 sessions, 25 
commands, default (16) names, and no Name Number 1 support for adapter 
1: 

LTSVCFG / S=12 C=25 N1=0 


- Request of 12 sessions, 25 commands, 20 names, and no Name Number 1 
support for adapter 0. Same values for adapter 1: 


LTSVCFG S=12 C=25 N=20 N1=0 / = 





Request of 10 sessions and Name Number 1 for support adapter 0. Also 12 
sessions, 25 commands, and no Name Number 1 support for adapter 1. For 
adapter 3 defaults and no Name Number 1 support and for adapter 4, 14 
sessions, 20 commands, 18 names and Name Number 1 support: 


LTSVCFG S=10 N1=1 / S=12 C=25 N1=0 / / S=14 C=20 N=18 N1=1 








LAN VDD Restrictions 


There can be only one OS/2 or DOS application per adapter that uses any 
given SAP number. 


+ There can be only one OS/2 or DOS NetBIOS application per adapter that 
uses Name Number 1 support. 


+ There can be only one OS/2 or DOS IEEE 802.2 application per adapter that 
uses Direct Station support. 


+ You cannot use the IBM LAN Support Program with the LAN VDD. 


* All DOS IEEE 802.2 commands are implemented with the exception of 
RECEIVE.MODIFY. 
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TCP/IP over LAN VDD 


To run TCP/IP over the VDD, it is first necessary to run LTSVCFG.COM with the 
parameter D=1. This is necessary because TCP/IP uses the direct station link of 
the 802.2 protocol. 





Examples: 
If running over adapter 0 
LTSVCFG D=1 





If running over adapter 1 
LTSVCFG / D=1 





If running over adapter 2 
LTSVCFG / / D=1 





A slash is used to signify the adapter number. LTSVCFG can be included in the 
AUTOEXEC.BAT file so that it runs automatically when you double-click on the 
TCP/IP icon. Regardless, LTSVCFG with the D=1 parameter must be run before 
running TCPSTART.BAT. 





When running the TCP/IP file transfer applications FTPD and FTP, it is necessary 
to clear the APPEND environment variable on both the server and client machines. 
This can be done by commenting out the APPEND statement: 


























REM LOADHIGH APPEND C:\0S2;C:\0S2\SYSTEM 
in the AUTOEXEC.BAT file or by entering 


APPEND=* 
































at the DOS command prompt. This is necessary because if the files being 
transferred display in the APPEND path of the destination machine, the APPEND path 
overrides the specified destination path. 




















Installing DOS LAN Services VDD 


To Install the DOS LAN Services Virtual Device Driver, follow the steps as 
described below: 


1. In the LAN Services folder, select LAN Services Installation/Configuration 
Program. 


2. Select OK on the logo panel. 
3. Select Tailored in the Easy or Tailored Installation/Configuration window. 


4. The Installation Tasks window is displayed. Select OK to accept Install or 
configure this workstation. The Installation/ Configuration window, which is 
shown in Figure 258 on page 415, will be displayed. 
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To change the install action, select the components you want and 
then select a pushbutton below. 


"Component Se oomnnnnes 


A 
a 


S/2 LAN Services Installation/Confé Installed 

raphical User Interface :Installed 

S/2 LAN Applications Development Not installed 

ser Profile Management ElInstalled 

irst Failure Support Technology/? / Installed 
Not installed 2Install 
Installed 


Installed 





Figure 258. OS/2 LAN Server 4.0 Installation and Configuration Window 


5. Select Virtual DOS LAN API Support from the Component field. 


6. Select Install. The Action field displays Install for the selected component. 
Then select OK to start the installation of the virtual drivers of DOS LAN 
Services. 


7. Exit the LAN Services installation/configuration program. 


You will be prompted to restart your workstation to make the changes active. 


Enabling a MVDM with DOS LAN API Support 


Before you set up a multiple VDM session, you need to create a DOS image 
diskette of a specific DOS version, for example IBM PC DOS 6.3, since DOS LAN 
Services cannot run in an emulated DOS session. Therefore, do the following: 


1. Install IBM PC DOS 6.3 on your LAN Server workstation using the following 
steps: 


a. Open a virtual DOS full screen session. Insert the first product diskette 
of IBM PC DOS 6.3 into drive A:, and issue the following command: 


A: SETUP /A 





b. At the LAN Server Administrator Option screen, change the target 
directory to, for example, d: IBMLAN DOS IBMDOS63. All files are 
being expanded while transferring. 


2. Create an IBM PC DOS 6.3 boot diskette. To do so, follow the next steps: 


a. Before opening the virtual DOS session (full screen or window), open the 
session settings by clicking the right mouse button on the icon, selecting 
Open and then Settings. 


b. Select the Session page and open the DOS Settings. 


c. Select DOS_VERSION setting, and add the FORMAT program to the 
Values: 


FORMAT.COM,6,30,255 
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d. After you have added the FORMAT program, select Save. Then close the 
Settings window. 


e. Now open a virtual DOS window (full screen or window) and insert a 
diskette in drive A: 


. Change to the server's directory d: IBMLAN DOS IBMDOS63 and issue 
the following command: 


+ 


FORMAT A: /U /S 
g. Copy the following lines to the diskette's CONFIG.SYS file: 





DEVICE=C: IBMLAN DOS IBMDOS63 HIMEM.SYS 
DOS=HIGH 

COUNTRY=001,437,C: \IBMLAN\DOS\IBMDOS63\COUNTRY. SYS 
D 

D 



























































DEVICE=C: \OS2\MDOS\FSFILTER. SYS 
DEVICE=C: \IBMCOM\PROTOCOL\LANVMEM. SYS 





































































































SHELL=C: \IBMLAN\DOS\IBMDOS63 \COMMAND.COM C: \IBMLAN\DOS\ 
FCBS=16,8 

FILES=40 

BUFFERS=16 

AASTDRIVE=Z 


h. Copy the following lines to the diskette's AUTOEXEC.BAT file: 


@ECHO OFF 

PROMPT [Sp] 

PATH C:\IBMLAN\DOS\IBMDOS63 
C:\IBMCOM\LTSVCFG S=12 C=14 N=8 
C:\OS2\MDOS\FSACCESS A: 


3. Create a DOS image file of the IBM PC DOS 6.3 boot diskette created in the 
steps before. To do so, issue the following command at an OS/2 command 
line: 































































































VMDISK A: C: IBMLAN DOS IBMDOS63 IBMDOS63.IMG 


4. Now create a DOS full screen session object for IBM PC DOS 6.3. To do so, 
open the Templates folder and drag the Program object and drop it onto a 
place you like on the Workplace Shell's folders or onto the Desktop itself. 

Edit the following entries to the program object: 















































Program, Path and file name: * 
Session, set radio button to DOS full screen 





BMDOS63 /] 





G] 





Session, DOS Settings, DOS_STARTUP_DRIVE: C:\IBMLAN\DOS\IBM 



































Title: DOS LAN Services 





Save the entries by selecting the Save button. 
5. DOS LAN Services must now be installed. Perform the following steps: 
a. Start the IBM PC DOS 6.3 session created in the step before. 
b. Copy C: CONFIG.SYS to C: OS2_ (backup copy) 
c. Copy C: AUTOEXEC.BAT to C: OS2 (backup copy) 


d. Copy the CONFIG.SYS file and the AUTOEXEC.BAT file from the IBM PC 
DOS 6.3 boot diskette created in the steps before to the C: directory. 
While installing DOS LAN Services, those configuration files will be 
updated. 


e. Insert the first product diskette of DOS LAN Services into drive A: and 
enter the installation command: 


A: INSTALL 
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DOS63\I 





DC 





Seal 


. Follow all instructions displayed. Set the installation path to C: NET 


g. When the installation has been completed, select Return to DOS and 
inspect your system files. Edit the C: AUTOEXEC.BAT file and ensure 
that the FSACCESS command is the very last statement. 


h. Now copy the C: CONFIG.SYS file and the C: AUTOEXEC.BAT file to the 
IBM PC DOS 6.3 boot diskette. 


i. Copy C: OS2 CONFIG.SYS to C: 
j. Copy C: OS2 AUTOEXEC.BAT to C: 





k. Close the DOS session by entering the EXIT command. 


. Recreate the DOS image file of the IBM PC DOS 6.3 boot diskette with 
the updated CONFIG.SYS and AUTOEXEC.BAT files. To do so, issue the 
following command at an OS/2 command line: 























VMDISK A: C: IBMLAN DOS IBMDOS63 IBMDOS63.IMG 















































Your DOS LAN Services installation is complete now. You can now load DOS 
LAN Services from an OS/2 MVDM session by double-clicking on the created 
icon. 


Installing Personal Communications in a MVDM Session of OS/2 V2.11 


In this sample installation, Personal Communications/3270 communicates with a 
token-ring network adapter bound to IBM IEEE 802.2 It uses the LAN virtual 
device driver. Check information in “Installing the LAN Virtual Device Driver’ on 
page 411. 


1. Open a virtual DOS Full Screen window, and insert the first product diskette 
in drive A:. Issue the following command from the command line: 





--A:\INSTALL------------------------------------------------------ 





2. Select the OK button as many times as you get the Personal 
Communications/3270 Installation window. 


3. Select Quick Installation. 


4. At the Install window, select the drive on which you want to install PC/3270. 
Do not allow the installation program to modify the AUTOEXEC.BAT file. 
Press the F8 function key to go to the next window. 


5. At the Attachment Type window, select LAN via 802.2 protocol as the 
attachment being used. Specify the number of host sessions. Then press 
the F8 function key to continue with the next window. 


6. At the LAN via 802.2 Protocol window, enter the destination address of your 
gateway, for instance 400032700001. If you use PU IDs in in your network, for 
instance FD802, enter the data accordingly. Block ID must be 061. PIU size 
is, for example, 0265. If all definitions are made, press the F8 function key to 
go to the next window. 


7. At the Screen, Keyboard and Printer window, specify screen size of your 
defined host session, for instance 24x80, and provide keyboard and printer 
information. Press the F8 key to continue with the next window. 


8. Press the F6 function key to start the installation process. After successful 
completion press the F3 key to exit the installation program. 
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9. You may now define PC/3270 as a DOS application to your Desktop by doing 
the following steps: 


a. From the Templates folder drag a Program icon to your Desktop. The 
Settings notebook will be opened. 


b. First, select the Program page and enter data as shown in Figure 259. 
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5 
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Required 





Optional 
Parameters: 
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Figure 259. Settings Notebook Program Page for PC/3270 


c. Select the Session page and then select the DOS window check box. 
Open the DOS Settings. 





















LEE ESET eee 5 
IDLE_ SENSITIVITY 
INT_DURING_IO 
KBD_ALTHOME_BYPASS 
KBD_BUFFER_EXTEND 
KBD_CTRL_BYPASS 
KBD_RATE_LOCK 
MEM_EXCLUDE_REGIONS 
MEM_INCLUDE_REGIONS 
MOUSE_EXCLUSIVE_ACCESS 
PRINT_SEPARATE_OUTPUT 
PRINT_TIMEOUT 
VIDEO_8514A_XGA_IOTRAP 
VIDEO_FASTPASTE 
VIDEO_MODE_RESTRICTION 
VIDEO_ONDEMAND_MEMORY 





© Description 


Use this setting to selact a period of 
allowable idle time before the operating 
system reduces the idle program's 
portion of processor time, 





\ 


Figure 260. Settings Notebook DOS Settings Page for PC/3270 


1) Select IDLE_SECONDS and set this value to 60. 
2) Select IDLE_SENSIVITY and set this value to 100. 


3) Select KBD_ALTHOME_BYPASS and set this value to On. This 
enables the PA2 function key for PC/3270. If this value is set to Off, 
you can switch this DOS session between DOS full screen and DOS 
window which surely is not necessary for PC/3270. 
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4) Select KBD_CTRL_BYPASS and set this value to ALT_ESC. This 
value allows you to switch among host sessions. 


5) If you like, select VIDEO_MODE_RESTRICTION and set this value to 
CGA to enable the Operator Information Area (OIA) to be displayed. 


6) Select the Save button to save the changes. 
d. Select the General page and name your application as, for example, 
PC/3270. 


By double-clicking on the new defined PC/3270 object, you can start Personal 
Communications/3270. 





Configuring WIN-OS/2 for Network Operation 
Prior to configuring WIN-OS/2 for network operations, you have to do the steps 
described in “Installing DOS LAN Services VDD” on page 414. 
To enable network support for WIN-OS/2 sessions do the following steps: 
1. From the OS/2 Desktop, open the OS/2 System folder. 
. Select the Command Prompts folder. 
. Select the WIN-OS/2 Full Screen object. 
. From the Program Manager, select the WIN-OS/2 Main icon. 
. Select WIN-OS/2 Setup icon. 


. From the Options pulldown menu, select Change system settings. 


N DO Oo fF WD DY 


. Click on the right drop-down list to see a list of choices. 
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Figure 261. WIN-OS/2 Setup System Settings (Network) 





8. From the list, select IBM OS/2 LAN Server (Version 1.3 CSD 5015/5050), and 
then select OK. 


9. Before you select OK on the downlevel software panel, insert any OS/2 
diskette. Then insert OS/2 diskettes as requested. The Setup program 
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installs the following three files in the OS2 MDOS WINOS2 SYSTEM 
directory: 





NETAP 20.D iL 
PMSPL20.DLL 
LANMAN . DRV 


























Note: You may select Microsoft LAN Manager (Version 2.1 Enhanced) if you 
want to overcome the 8 byte restrictions (concerning user IDs, 
machine names, domain names, and so on). 


10. To make the DLL files useable, change to the OS2 MDOS WINOS2 SYSTEM 
directory and rename the DLL files as follows: 





REN NETAPT20.DLL NETAPI.DLL 
REN PMSPL20.DLL PMSPL.DLL 






































If you have DOS or Windows applications that require DOS NetBIOS or DOS IEEE 
802.2 support, refer to the sections earlier in this chapter for more information. 
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Appendix A. Migration and Backup Utilities 


The following information describes utilities that help you to migrate from 
previous versions of LAN Server, and to back up files when changing from a file 
system that does not contain access control profiles (FAT) to a file system that 
does (386 HPFS). The following utilities are described: 


BACKACC 
FIXACC 
HDCON 
PREPACL 
* RESTACC 
* THIN386 


BACKACC Utility 


Purpose 


* Copies the NET.ACC file. This file contains the user and group accounts 
database information. It also contains access control profile information for 
non-386-HPFS file system resources. 


* Copies the NET.AUD file. This file contains audit log information for the 
server. 


* Backs up access control profiles for files and directories. 


Deletes access control profiles for nonexistent directories. 


Syntax 


This command has the following syntax: 





--BACKACC = a lear 
-d: pathname 





-/F:d: target -/A- -/S- -/V- 





-/L1:\pathname\ filename 


Parameters 
You can use the following parameters with the BACKACC utility: 
d: Specifies an optional drive letter. 
pathname Specifies the path to the directory or file for which permissions are to 
be backed up. 


If pathname is omitted, the BACKACC utility makes copies of only the 
user and group accounts database (NET.ACC) and audit log 
(NET.AUD). The resulting backup copies are named NETACC.BKP 
and NETAUD.BKP and are stored in IBMLAN ACCOUNTS and 
IBMLAN LOGS respectively. 


The BACKACC utility accepts wildcard characters in the path name. 
If pathname is a directory, the permissions for the directory and all 
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Remarks 


files in the directory are saved. Only explicit (non-default) 
permissions are saved. 


IF:target Specifies a target file to store access control profile information to be 


IA 


IS 


N 


used by the RESTACC utility. If target is not an absolute path name, 
the default directory for target is the current working directory. 


If /F:target is not specified, ACLBAKd.ACL is used, where d is the 
drive letter of the drive on which the resources whose access control 
profiles are being backed up reside. The directory is 

IBMLAN ACCOUNTS. 


If the access control profile backup file is created on a 386 HPFS 
partition, the BACKACC utility retains the permission information 
contained in the backup file when updating it. A new backup file is 
created with only read permission granted to the local ID plus 
whatever permissions are implicitly inherited from the parent 
directory. 


Updates the target file instead of overwriting it. The default action is 
to overwrite the target file. If /A is specified, permission information 
for file and subdirectories specified in pathname are updated or 
added, and other resource permissions already in the file are 
preserved. 


Backs up all descendant subdirectories. This switch is valid only if 
pathname is a directory, in which case it recursively backs up 
permissions on all resources in all descendant subdirectories. If 
pathname is not a directory, this option is ignored. 


Causes the names of the access control files to be displayed as they 
are being backed up by the BACKACC utility. 


/L1: pathname filename 


Is an optional set of parameters that specifies where the LAN 
Configuration Installation Distribution Utility (LAN CID Utility) writes its 
log file. If absent, the logging output is written directly to the screen. 
See the LAN Server Network Administrator Reference Volume 1: 
Planning, Installation, and Configuration for more information on the 
LAN CID Utility. 


Log on locally as an administrator to use the BACKACC utility on a 
workstation installed with local security. In addition, you must have access 
to the \IBMLAN\ACCOUNTS subdirectory and to the root directory of the 
drive you are using. 


* XCOPY does not copy access control profiles associated with the directories 


and files that it copies. Use BACKACC and RESTACC in conjunction with 
XCOPY to copy data and its associated access permissions. 


In addition to performing account and audit file backup, the BACKACC utility 
performs backups of the specified file access permissions. 


* The BACKACC utility extracts the access control profiles for the files 


specified by pathname and stores them in symbolic form in target. 


* This utility should be run prior to running the OS/2 Backup utility, which does 


not back up permissions information. 
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Examples 


The following example makes backup copies of NET.ACC and NET.AUD. The 


example replaces the target file ACLBAKC.ACL with the access control 
information associated with the C: resource. No subdirectory information is 


retained. 
BACKACC C: 


The following example backs up NET.ACC and NET.AUD and replaces the target 


file ACLBAKE.ACL with access control information associated with E: and all 
access control profiles under E: . 


BACKACC E: 





/S 


The following example backs up NET.ACC and NET.AUD and updates the target 


file OS2D.ACL with the access control information associated with D:\OS2 and 


the subdirectories below it. 


BACKACC D: OS2 /F:C: 








BACKUP\0OS2I 





D.ACL /A /S 


The following example backs up NET.ACC and NET.AUD and replaces the target 
file ACLBAKC.ACL with the access control information associated with 


MYFILE.DOC. 


BACKACC C: \EI 














DOCS \MYF 





LE 





i. DOC 








To create a backup of the NET.ACC file at each startup, add the following 


statement to the STARTUP.CMD file: 


BACKACC /S 


At the next system restart, a copy of the current NET.ACC file is saved. 


Note: The BACKACC utility does not require that you stop the server. 





FIXACC Utility 


Purpose 


Syntax 


When the LAN Server program performs updates to the information in the 
NET.ACC file, it sets a flag in the file to “in use,” updates the file, then resets the 


“in use” flag. If a condition occurs that prevents the LAN Server program from 


completing an update and resetting the “in use” flag, the NET.ACC file is 


considered unusable by the LAN Server program. If this happens, there might 


be only one bad record in the file, and the rest of the file can be recovered. The 


FIXACC utility reads the damaged NET.ACC file directly and builds a new one. 
When it is finished, the FIXACC utility resets the “in use” flag so that the LAN 


Server program will recognize the new NET.ACC file as valid. 


This command has the following syntax: 





--FIXACC- 
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Parameters 


Remarks 


Example 


HDCON Utility 


Purpose 


Syntax 


Parameters 


This utility has no parameters. 


* The FIXACC utility cannot be run under local security. Before using the 
FIXACC utility, use the LAN Services installation utility to remove the local 
security component of the OS/2 LAN Server program. 


* You cannot run the FIXACC utility while User Profile Management is running 
or after the requester is started. 


+ The FIXACC utility logs errors to a file named FIXACC.LOG. If a FIXACC.LOG 
file exists, it is copied to FIXLOG.BKP. In addition, the FIXACC utility logs 
progress messages so you can review the work performed by the FIXACC 
utility. 


To restore the information in the damaged NET.ACC file, type the following at the 
OS/2 command prompt and press Enter: 


FIXACC 





Migrates users' home directory aliases from releases of LAN Server prior to LAN 
Server 2.0 into the format used by the current version. When this is 
accomplished, the old aliases are deleted. The utility also creates aliases for 
home directories created in LAN Server 2.0 or later for those users who are 
accustomed to or need the previous format. 


This command has the following syntax: 


- -HDCON ro) * ~---------------------------- 











n user 


You can use the following parameters with the HDCON utility: 
-O Converts to old format. 
-n Converts to new format. 


* (asterisk) 
Converts all users on the domain. 


user Specifies a user ID to convert. You can list more than one user ID on 
the command line. 
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Remarks 


* The HDCON utility can convert all users in a domain at one time or convert a 
list of users provided at the OS/2 command prompt. 


Only a user with administrative authority can use the HDCON utility to 
migrate users' home directories. The command must be used at the domain 
controller. 


Examples 
The following example converts all users in the domain to the old format: 
HDCON -o * 





The following example converts a list of user IDs (NANCY, KIM, and GWEN) to 
the new format: 








HDCON -n NANCY KIM GWEN 














PREPACL Utility 


Purpose 


Backs up, removes, and restores 386 HPFS access control profiles applied to any 
subdirectories or files that are required to install a new version of OS/2. 


Syntax 


Use the following form of the syntax to remove access control profiles: 





-~-PREPACL--/P Seuss = /Petitename. Ss2scsesceseessot eee: 
-/FL: filename /N--------- 
-/DL: filename 
-/D:dirname -- 




















eo a eve eh Sy IP | ey ae Ss Rete Meee Ea Se Sn Rye 5 /O----- 
-/L1:d:\pathname\ filename -/L2:d:\pathname\ filename 


--/LR:d:\pathname - = Hance 7 = = Eee ee 





Use the following syntax form of the syntax to restore access control profiles: 











--PREPACL--/R--/B:d:\pathname\ filename ore aha Pa aan ka cin mR AR 
-/L1:d:\pathname\ filename 








-/L2:d:\pathname\ filename 


Parameters 
You can use the following parameters with the PREPACL utility: 
d: Specifies any drive letter. 
filename Specifies the file in the specified directory or subdirectory. 


pathname Specifies the directory or subdirectory on the specified drive. 
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IP 


IR 


Removes 386 HPFS access control profiles in preparation for OS/2 
installation. 


Restores previously removed access control profiles. 


/FL: filename 


Specifies an ASCII file containing a list of subdirectories from which to 
remove access control profiles. All access control profiles for the 
specified files and paths to those files are removed. 


For example, if you specify /FL:A: props.txt, and PROPS.TXT 
contains the entry C: X script.txt, the access control profiles 
associated with the following files, directories, and paths are 
removed: 


C: (drive) 
C: (root directory) 
C: X (subdirectory) 


C: X script.txt (file name) 


This parameter is optional and cannot be used with the /DL or /D 
parameter. 


/DL: filename 


/D: dirname 


/B: filename 
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Specifies an ASCII file containing a list of subdirectories from which to 
remove access control profiles. If the /DL parameter is specified, the 
access control files associated with the following files, directories, 

and paths are removed: 


* Specified subdirectories in the list 

- All files in the specified subdirectories 

* All drives and subdirectories in the path of the specified 
subdirectories 

* All subdirectories and files contained in subdirectories under the 
specified subdirectories 


For example, if you specify /DL:A: filename, and the specified 
filename contains the entry C: , the entire C drive is affected. 





This parameter is optional and cannot be used with the /FL or /D 
parameter. 


Specifies a single subdirectory from which to remove access control 
profiles. 


Note: 
The effect of this parameter is identical to the effect of the /DL 
parameter followed by a file that contains only one subdirectory. 


This parameter is optional and cannot be used with the /FL or /DL 
parameter. 


When removing access control profiles, specifies a file name in which 
to save the access control profiles. If this parameter is not used, /N 
must be specified. 


When restoring access control profiles, specifies the file containing 
the access control profiles to be restored. 


Specifies that the access control profiles should be removed but not 
backed up. If this parameter is not used, /B must be specified. 


Remarks 


IL1:d: pathname filename 


Specifies a remote error log in addition to the 

OS2 INSTALL IBMLANER.LOG file on the local workstation. This 
parameter is optional. Use it if you are running the PREPACL utility 
remotely. 


/L2:d: pathname filename 


10 


Specifies a remote history log in addition to the 

OS2 INSTALL IBMLSHST.LOG file on the local workstation. This 
parameter is optional. It is used primarily if you are running the 
PREPACL utility remotely. 


Specifies to remove access control profiles using only the /FL, /DL, or 
/D parameters set in this command. If this parameter is not specified, 
the PREPACL utility uses the /FL, /DL, or /D parameters in addition to 
any internal checklists generated by the OS/2 2.1 and the LAN Server 
installation programs. See the LAN Server Network Administrator 
Reference Volume 1: Planning, Installation, and Configuration for more 
information on internal checklists. 


/LR:d: pathname filename 


Specifies the path to the IBMLAN subdirectory. Specify this 
parameter only if you run the PREPACL utility under the operating 
system booted from the 386 HPFS diskette (for example, in case of a 
fixed-disk failure). Refer to the LAN Server Network Administrator 
Reference Volume 1: Planning, Installation, and Configuration for 
information on using the 386 HPFS boot diskettes to run the PREPACL 
utility. 


Use the PREPACL utility only during a local installation, not during a remote 
installation with the LAN Configuration Installation Distribution Utility (LAN 
CID Utility). 


* You must run the PREPACL utility prior to installing OS/2 2.1 to remove the 
access control profiles from the subdirectories and files on 386 HPFS drives. 
Then run the PREPACL utility again to restore the access controls after you 
have installed OS/2 2.1. 


To remove the access control profiles and restore access controls: 


1 


4 
5 


Note: 


Run the PREPACL utility to remove the access control profiles from 
subdirectories and files on 386 HPFS drives on which OS/2 2.1 and the 
THIN386 utility are to be installed. 


Install OS/2 2.1 using diskettes. 


If you did not specify the whole drive when you ran PREPACL, you 
might need to run the THIN386 utility before continuing. 


Install LAN Server. 


Run the PREPACL utility to restore the access controls. 


The PREPACL.EXE program is on the Server 1 diskette. Run the utility only 
from a backup of this diskette. 
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Example 


RESTACC Utility 


Purpose 


Syntax 


Parameters 


Use the following steps to back up your 386 HPFS access control profiles on 
drive C: to a file named OLDPROFL and remove them from the file system: 


To backup 386 HPFS access control profiles and remove them from the file 
system: 


1 Insert Server Install/Diskette 1 into drive A. 


2 Atthe [A: ] prompt, type the following command and press Enter: 





PREPACL /P /B:C: OLDPROFL /D:C: 














The preceding command removes and backs up all the access control profiles in 
drive C:. 


Restores access control profile information for any file system resources backed 
up by the BACKACC utility. 


This command has the following syntax: 





--RESTACC- - ----- -pathname- - --------------— -------- 
-dr ------- newname -/F:------ source 
-dr -dr 








-/L1:\pathname\ filename -/S- -/V- 


You can use the following parameters with the RESTACC utility: 
d: Specifies an optional drive letter. 


pathname Specifies the directory or file whose access control profiles are 
restored. If wildcard characters are specified, newname cannot be 
specified. 


newname Specifies a new file or directory that is to receive the permissions for 
the file or directory associated with pathname. The existing 
permissions for newname (if any) are replaced with the restored 
permissions. 


IF:source Uses source as the source of backed-up access control profiles. If 
source is not specified, the same naming convention is used to 
construct the source name as for the BACKACC utility. 


IS Restores subdirectories. This switch is valid only if pathname is a 
directory and newname, if specified, is a directory. 
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Remarks 


Examples 


/L1: pathname filename 


Is an optional set of parameters that specifies where the LAN 
Configuration Installation Distribution Utility (LAN CID Utility) writes its 
log file. If absent, the logging output is written directly to the screen. 
See the LAN Server Network Administrator Reference Volume 1: 
Planning, Installation, and Configuration for more information on the 
LAN CID Utility. 


Causes the names of the access control files to be displayed as they 
are restored by the RESTACC utility. 


- The RESTACC utility extracts permissions stored in source by the BACKACC 


utility for the files resource pathname and restores the permissions to 
newname. If no newname is specified, the original path name is assumed. 
This utility is to be run after restoring a HPFS volume in order to restore the 
access permissions for the file system in the actual file system structure. 


Note: 
In order to run the BACKACC utility on a machine installed with local 
security, you must have administrative authority. 


«+ When a file is restored on a 386 HPFS drive by a utility that is not aware of 


the 386 HPFS method for storing permission information (for example, the 
OS/2 RESTORE utility), the files and directory structures are treated as new, 
and standard 386 HPFS inheritance rules apply. 


Note: 
The RESTACC utility cannot restore the file permissions to their prebackup 
state unless the BACKACC utility was run during backup. 


Because the BACKACC and RESTACC utilities back up and restore user 
names associated with the access control profiles (instead of user IDs), user 
names are discarded if they have been deactivated since the backup. 


* The RESTACC utility can be used to restore user names on an additional 


server, but when the additional server is started it is synchronized with the 
user defaults from the domain controller. After you run RESTACC on an 
additional server, you might have to change the additional server's USERID 
password. 


The following example restores the access control information stored in the 
ACLBAKE.ACL file. ACLBAKE.ACL is the default file for drive E. 


RI] 





ESTACC E:\ /S 





The following example restores the access control information stored in the 
OS2D.ACL file: 


RI] 





ESTACC D: OS2 /F:C: BACKUP\OS2D.ACL /S 








The following example restores the access control information stored in the 
ACKBAKC.ACL file to the MYFILE.NEW file: 


RI] 




















ESTACC C:\EDOCS\MYFILE.DOC MYFILE.NEW 
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THIN386 Utility 














Purpose 
The THIN386 utility creates a modified 386 HPFS file system that enables OS/2 
2.1 to access files that are protected by 386 HPFS access control profiles during 
LAN Server installation. 
Syntax 
This command has the following syntax: 
--THIN386--/B:d@ -/T:e:\path - - - ---— - - - - 
-/L1:f:\path\filename 
-/L2:g:\path\ filename 
Parameters 
You can use the following parameters with the THIN386 utility: 
IB:d: Specifies the boot-drive letter where CONFIG.SYS is located. 
/T:e: path Specifies the path on which to install the temporary 386 HPFS. If the 
subdirectory does not exist, it is created. 
/L1:f path filename 
Specifies a remote error log other than the 
OS2 INSTALL IBMLANER.LOG file on the local workstation. This 
parameter is optional. Use it if you are running the THIN386 utility 
remotely. 
/L2:g: path filename 
Specifies a remote history log other than the 
OS2 INSTALL IBMLSHST.LOG file on the local workstation. This 
parameter is optional. Use it if you are running the THIN386 utility 
remotely. 
Remarks 


* You can use the THIN386 utility in the following types of installations: 


- An unattended remote installation using the LAN CID Utility on a 386 
HPFS workstation. 


- An attended local installation of OS/2 2.1 and LAN Server - Advanced on 
a 386 HPFS workstation. 


Note: 
This utility can be run only on a workstation that has OS/2 2.1. (or higher) 
installed. 


+ You do not need to use the THIN386 utility if you have run the PREPACL 
utility specifying the whole drive, or all directories that contain access 
control profiles. 
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Example 


Use the following steps to create a temporary 386 HPFS: 
To create a temporary 386 HPFS: 
1. Insert Server/Install Diskette 1 into drive A. 


2 Atthe [A: ] prompt, type the following command and press Enter: 





THIN386 /B:C /T:Z: TEMP TEMPFS 

















The preceding command specifies that the CONFIG.SYS file is located on drive 
C: and installs the temporary 386 HPFS on drive Z: in the subdirectory 
TEMP TEMPFS. 


Note: 


Ensure that the subdirectory specified by the /T parameter is on the OS/2 2.1 
boot drive. 
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Appendix B. 


Network SignON Coordinator/2 


LAN Server is further enhanced with the inclusion of a productivity aid to 
automate user's security signons and synchronize password changes across 
multiple LAN Servers and/or host systems. 


Network SignON Coordinator/2 provides the user a signon and a signoff function. 
A signon, change password, or signoff operation is referred to as a request. The 
signon function requires the user to enter a user ID and password. The user data 
is combined with information previously defined in the configuration file (NSC.INI) 
and, based on the requests defined in NSC.INI, the user may be logged on 
multiple LAN Server domains, NetWare servers or host systems by providing an 
interface to the different access control functions, referred to as Locations. The 
signon function also accepts an optional new password. When a new password 

is entered, a password change is initiated for all signon operations. The signoff 
function logs the user off those systems they were logged on to by signon. 


Note: In this appendix we will discuss how to install and configure Network 
SignON Coordinator/2 in the OS/2 LAN Server 4.0 environment. See the online 
reference for details of how you may use Network SignON Coordinator/2 in other 
environments. 


Network SignON Coordinator/2 Overview 


© Copyright IBM Corp. 1995 


The Network SignON Coordinator/2 Client provides the end user a way to 
perform a signon/signoff operation. The client can operate on either an OS/2 or 
DOS platform and may signon/signoff domains, NetWare servers, hosts, and 
local facilities. These operations are specified in a user configured ASCII file 
(NSC.INI) which contains the location definitions which may contain a user ID to 
be used for request processing. The same location can be defined as many 
times as is necessary to include all the user IDs that you have at that location. 
Network SignON Coordinator/2 will prompt you for your current password and 
user ID (if not already specified in NSC.INI) which is then combined with location 
information to process your request. 


The LAN Server operation, that we are concentrating on in this appendix, 
specifies a signon operation for LAN Server domains and the name of the 
domains. There are options to: 


Use a different user ID than the one the end user inputs. 
Specify that the user is to be logged on to a specific Domain. 


Specify an exit routine to be executed after Network SignON Coordinator/2 
performs the signon/signoff operation. Network SignON Coordinator/2 allows 
a user to signoff all locations with a single command. 


Change password across all defined domains in one operation. 


If the user selects the option to change passwords, the user is prompted to 
enter and confirm the new password. The password change is then initiated 
at all locations defined in their Network SignON Coordinator/2 configuration 
file. 
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Network SignON Coordinator provides additional functions and options to allow 
users to tailor the system to fit their needs. These functions and options include: 


Queueing requests to LAN Server domain controllers when they are not 
available. 


- The ability to specify different user IDs on each system while using the same 
signon password on every system. 


* An OS/2 API and toolkit that supports all of the function of Network SignON 
Coordinator/2 while bypassing the user interface. 


User Exits for additional coordination or synchronization of signons, changing 
passwords and signoffs. 


Configuration options for user ID character set, min/max user ID length and 
min/max password length. 


To summarize, Network SignON Coordinator/2 is a tool for end users who, by 
entering their user ID and password once at a menu, have their signon requests 
processed at any number of OS/2 LAN Server domain controllers. 


Note: Users in a double-byte character set (DBCS) environment are limited to 
using single-byte characters in their user IDs and passwords. 


Network SignON Coordinator/2 Program Requirements and Functions 


Network SignON Coordinator/2 operates in three different configurations. The 
Network SignON Coordinator/2 Server configuration is not relevant in the context 
of LAN Server domains and therefore, you should refer to the online reference 
that is installed with the product for details of this component. In this section, we 
will look at the following two configurations and their functionality in the OS/2 
LAN Server 4.0 environment: 


DOS Clients 
OS/2 Clients 


DOS Client Requirements and Function 
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The Network SignON Coordinator/2 DOS Client requires: 
IBM or MS-DOS Version 3.3, or above 
NetBIOS support 
For OS/2 LAN Server domain signons, either require: 


- IBM PC Local Area Network Program (PCLP) 1.34 
- DOS LAN Requester 2.0 or later 


to be installed. 
« For NetWare logins, only the NetWare requester shipped with NetWare 3.11 
or higher is required. 
The DOS Client provides the following function: 


* The DOS Client can request a LAN Server logon to a domain using the LAN 
Server signon operation. 
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Notes: 


1. If the user requests a password change while signed on to a LAN Server, the 
user remains logged on. If, however, the user is not signed on, then the 
user is signed on, the password is changed and the user is signed off. 


2. If you incorrectly enter your password from a DOS LAN Services DOS Client, 
Network SignON Coordinator/2 will not currently detect that the password 
has not been validated by the LAN Server domain. You should sign off and 
back on again in these circumstances. 


OS/2 Client Requirements and Function 
The Network SignON Coordinator/2 OS/2 Client requires: 


OS/2 1.3 or higher 
NetBIOS support 


For LAN Server domain signons, OS/2 LAN Requester or OS/2 LAN Server 
Version 2.0 or later are required. 


For NetWare logins, only the OS/2 NetWare requester shipped with NetWare 
3.11 or higher is required. 


The Network SignON Coordinator/2 OS/2 Client has the following functions: 


+ It can request a signon, password change or signoff for the LAN Server 
domain. 


If a LAN Server does not respond to a request, the OS/2 Client can place a 
request on a retry queue if the NSC Retry Process has been started. 


RAM and DASD Requirements 


Static memory and fixed-disk space requirements for Network SignON 
Coordinator/2 are provided in the following table: 


Table 27. Network SignON Coordinator/2 RAM and DASD Requirements 
Requirement DOS Client OS/2 Client 
Memory 160KB 170KB 
Fixed Disk 230KB 640KB 





Notes: 


1. Does not include dynamic memory allocated for buffering locally accessed configuration and 
host information files. 


2. If you do not require APPC host connections, the fixed-disk requirement of the OS/2 Client 
may be reduced by 95KB by deleting the sample Communications Manager configuration file. 











Network SignON Coordinator/2 NetBIOS Requirements 


The Network SignON Coordinator programs require the following NetBIOS 
resources: 


NSCNDMN 


- 6 sessions 
- 6 commands 
- 1name 


NSCRETRY 


- 1 session 
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- 1 command 
- 1 name 


NSC (or NSCPM, NSCRSON or NSCRSOFF) 


- 1 session 
- 1 command 
- 1name 


You may configure the NetBIOS sessions and commands required by NSCNDMN 
as command line parameters to the NSCNDMN program. The number specified 
determines how many concurrent Network SignON Coordinator/2 Client requests 
the Network SignON Coordinator/2 Server can process. The default is for the 
NSC Server to request 6 sessions and 6 commands, but fail only if it is allocated 
less than 2 sessions or 2 commands. 


If you have not configured enough NetBIOS resources, the NSC process will fail 
when it is started and the following message is logged and displayed: 





NB 01 tt:tt:tt ResAlloc add nn more SESSIONS, nn more NCBS, and nn more NAD 

















In the message, nn is the number of additional resources needed to successfully 
start the NSC process. 


These NetBIOS resources are configured in the PROTOCOL.INI file located in the 
C:\NET directory for DOS LAN Services Clients and C:\IBMCOM directory for 
OS/2 Clients. The parameters are specified in the NETBEUI section of the file as 
follows: 





SESSIONS = nn 
NCBS = nn 
NAMES = nn 




















Note that NCBS is equivalent to commands. These parameters should be modified 
to include the requirements for each Network SignON Coordinator/2 program 

that will run concurrently on the workstation. You must restart the workstation for 
the new resource allocations to take effect. 


For example, on an OS/2 Client where NSCRETRY will be running when a signon 
is performed, each of these three parameters should be increased by four. On a 
Network SignON Coordinator/2 Server where NSCNDMN and NSCRETRY will be 
running, the parameters should be increased by 18, 10 and 18 respectively. 


Note: Network SignON Coordinator/2 only registers NetBIOS names that begin 
with NSC. Network SignON Coordinator/2 may be incompatible with a NetBIOS 
application that also attempts to register names beginning with NSC. 





Network SignON Coordinator/2 Security Considerations 


Network SignON Coordinator/2 is not a security product; it is a productivity aid. 
However, since it does help the user manage passwords, some care has been 
taken to avoid creating additional security exposures for the user. 


Review the following with respect to your security requirements: 


Network SignON Coordinator/2 assumes the user has the same password at 
all locations. If a user's password is compromised, the security exposure 
may be greater since all locations can be accessed with that password. 
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If this exposure is unacceptable, you should not use Network SignON 
Coordinator/2. 


Network SignON Coordinator/2 can remember the user's password once it 
has been entered, but only if this option (SAVEPW) is configured. The default 
operation requires the user to reenter the password each time it is required. 


The password is always discarded when Network SignON Coordinator/2 is 
terminated, even if SAVEPW is configured. 


Network SignON Coordinator/2 does not keep passwords in the clear in 
memory except when necessary to call external application programming 
interfaces. The password is masked and distributed using a simple 
reversible algorithm designed to prevent casual viewing of the password. 


Network SignON Coordinator/2 does not send passwords from Network 
SignON Coordinator/2 Clients to Network SignON Coordinator/2 Servers in 
the clear. The password is disguised to prevent casual viewing of the 
password via network analyzers. 


Products supported by Network SignON Coordinator/2 send the passwords 
across the network using different techniques. For information on how 
passwords are communicated by these products, consult the product 
information for that product. 


Network SignON Coordinator/2 provides no function for restricting access to 
locations. Access to other locations is controlled by each location's security 
facility. 


Network SignON Coordinator/2 performs no encryption and is therefore not 
subject to any export restriction related to encryption. 





Network SignON Coordinator/2 Installation 


This section describes how to install the Network SignON Coordinator/2 ona 
workstation. You can install Network SignON Coordinator/2 on a workstation in 
one of four configurations: 


+ Network SignON Coordinator/2 DOS Client 
Network SignON Coordinator/2 OS/2 Client 
Network SignON Coordinator/2 Server 


Network SignON Coordinator/2 OS/2 Client and Network SignON 
Coordinator/2 Server 


- This allows a workstation to function as both an Network SignON 
Coordinator/2 OS/2 Client and an Network SignON Coordinator/2 Server. 
In this case, you should perform the install for both the Network SignON 
Coordinator/2 OS/2 Client and the Network SignON Coordinator/2 Server. 


We will concentrate on the installation procedures related to the LAN Server 
product; the DOS and OS/2 Client installations. 


All installation instructions assume that the installation diskette (or its image) is 
in the current drive and that your current directory is the root of that drive. Using 
a diskette for example: 

A: 

CD \ 
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will put you in the correct place to proceed with the installation instructions. 


If you have a LAN Server and have copied the installation diskette onto its hard 
disk, you can perform the installation across a LAN. You should copy the 
installation diskette into a separate directory on the LAN Server's disk. At the 
LAN server: 





MD D:\NSCDISK 
CD D: \NSCDISK 
XCOPY A: /S 

















Assuming you have the LAN Requester running on the workstation you only 
need to switch to a drive that logically represents the directory containing the 
Network SignON Coordinator/2 install diskette image. For example, if N is a 
redirected drive, the following commands prepare the requester for installation. 


N: 
CD \ 





The following installation options are available: 
Network SignON Coordinator/2 DOS Client 
Network SignON Coordinator/2 OS/2 Client 
Network SignON Coordinator/2 Server 


Network SignON Coordinator/2 DOS Client Installation 


To install Network SignON Coordinator/2 on a DOS workstation, follow these 
steps: 


1. You must choose whether or not to install Network SignON Coordinator/2 in 
an existing directory or make a new one. Use the following list to decide 
which option to select: 


Existing 


You can pick a directory that already exists and is specified in your 
AUTOEXEC.BAT PATH statement. Making this choice avoids the need 
to update your PATH and create a new directory. 


This directory must also be specified in an APPEND command. The 
APPEND command is typically executed in your AUTOEXEC.BAT. 


New 


If you want to keep Network SignON Coordinator/2 in its own 
directory, then you must: 


- Create a directory for the Network SignON Coordinator/2 
program files. 


- Update the AUTOEXEC.BAT PATH statement. 
- Update or add an APPEND statement to AUTOEXEC.BAT. 


2. Assuming the directory you selected in Step 1 was C: \NSC, use the following 
command: 


INSTALL C:\NSC 
This completes the installation of the DOS client. Refer to the “Network SignON 


Coordinator/2 Configuration” on page 441 for details of how to configure the 
client. 
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The Network SignON Coordinator/2 DOS Client consists of 13 files: 


NSCRSON.EXE - signon command line/full screen executable 
* NSCRSOFF.EXE - signoff command line/full screen executable 
* NSCNET.EXE - LAN Server interface program 
NSC.INI - default configuration file 
NSCREAD.ME - README file 
NSCVERSN.LVL - product version level information 
NSC.EXE - program providing command line execution as well as the menu 
or graphical user interface 
NSC.PIF - Windows program information file 
NSCVM.HIF - sample VM host information file 
NSCVMOV.HIF - sample VM with OfficeVision/VM host information file 
* NSCMVS.HIF - sample MVS host information file 
* NSCOS400.HIF - sample OS/400 host information file 
NSCIIN.HIF - sample IBM Information Network host information file 


The NSCREAD.ME file is on the installation diskette in the root directory as 
READ.ME. The other files are on the installation diskette in the \DOSCL directory. 


The Network SignON Coordinator Configuration File (NSC.INI) may be replicated 
to multiple directories to allow support of different users or different system 
views. A copy of the file must either reside in the current directory or a directory 
specified in an APPEND when executing NSCRSON or NSCRSOFF. 


Network SignON Coordinator/2 OS/2 Client Installation 
To install the Network SignON Coordinator/2 OS/2 Client, follow these steps: 


1. You must choose whether or not to install Network SignON Coordinator/2 in 
an existing directory or make a new one. Use the following list to decide 
which option to select: 


Existing 


You can pick directories that already exists and are specified in your 
CONFIG.SYS PATH, LIBPATH, and DPATH statements. Making this choice 
avoids the need to update CONFIG.SYS and create new 

subdirectories. 

















The executable files and NSC.INI file must be placed in the directory 
specified by PATH and DPATH. The dynamic link library has to be 
installed in a directory specified by your LIBPATH. 

















New 


If you want to keep Network SignON Coordinator/2 in its own 
directory, then you must: 


- Create at least one directory. 





- Update the CONFIG.SYS PATH and DPATH statement for the 
executables. 





- Update LIBPATH for the dynamic link library. 


2. To install the Network SignON Coordinator/2 OS/2 Client use the following 
command: 











INSTALL 


You will then be prompted to select what function you wish to install. The list 
is displayed as follows: 
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1. -- NSC OS/2 Client 

2. -- NSC OS/2 Server 

3. -- NSC OS/2 Client and Server 
4. -- Quit. Don't install anything 








3. To install the OS/2 Client select option 1 and press enter. 


4. You will then be prompted to specify the directories where the executable 


files and dynamic link library (DLL) files are to be stored. 


5. When prompted whether you want to add Network SignON Coordinator/2 


Retries to the Startup folder, choose Y to have it added (see “Network 
SignON Coordinator/2 Support Processes” on page 447 for further 
information about the NSCRETRY support process). 


This completes the installation of the OS/2 client. 


The NSC OS/2 Client consists of nineteen files: 


NSC.EXE - PM executable program for Sign On and Sign Off 
NSCRSON.EXE - Sign On command line/windowable executable 
NSCRSOFF.EXE - Sign Off command line/windowable executable 
NSCRETRY.EXE - Retry Queueing executable 

NSCAPI.DLL - API and common code 

NSCUG.INF - information file for on-line documentation 

NSC.INI - default configuration file 

NSCRSIGN.LIB - library containing the NSCRSIGN API 
NSCRSIGN.H - C header file for the NSCRSIGN API 
NSCREAD.ME - README file 

NSCVERSN.LVL - product version level information 
NSCSAMPL.CFG - sample Communications Manager file for APPC 
NSCPM.EXE - Presentation Manager graphical interface program 
NSCHELP.HLP - online help information file 

NSCVM.HIF - sample VM host information file 

NSCVMOV.HIF - sample VM with OfficeVision/VM host information file 
NSCMVS.HIF - sample MVS host information file 

NSCOS400.HIF - sample OS/400 host information file 

NSCIIN.HIF - sample IBM Information Network host information file 


The NSCREAD.ME file is on the installation diskette in the root directory as 
READ.ME. The other files are on the installation diskette in the \OS2CL directory. 


Once you have installed a NSC OS/2 Client, entering: 





VIEW NSCUG 











will allow you to view the on-line documentation. This requires that either the 
directory where the non-DLL files were installed either be the current directory 
or in the DPATH. 





The Network SignON Coordinator Configuration File (NSC.INI) may be replicated 
to multiple directories to allow support of different users or different system 

views. A copy of the file must either reside in the current directory or ina 

directory specified in the DPATH when executing NSC, NSCRSON, NSCRSOFF or 
calling the NSCRSIGN API. 





Inside OS/2 LAN Server 4.0 


Network SignON Coordinator/2 Configuration 


This section contains information on how to configure Network SignON 
Coordinator/2 in an OS/2 LAN Server 4.0 environment. 


All configuration information for Network SignON Coordinator/2 itself is stored in 
a flat ASCII file called NSC.INI. An ASCII file editor can be used to modify the file 
to customize the configuration. The NSC.INI file comes with the defaults for menu 
interaction. Configurable entries include minimum and maximum user ID and 
password lengths, sound, menu shortcut, and default user ID. The NSC.INI file 
does not come with any preconfigured LAN Domain Server or host names. 
Entries for each LAN Server and host must be added. See the “Network SignON 
Coordinator/2 Configuration Options” for a description of each option in the 
configuration file. 


The default NSC.INI file for an OS/2 client only contains the following line: 
LOCAL, ON 


The NSC.INI file may be replicated to multiple directories to allow support of 
different users or different system views. A copy of the file must either reside in 
the current directory or in a directory specified in the DPATH (APPEND for DOS) 
when executing NSC, NSCRSON, NSCRSOFF or calling the NSCRSIGN API. 














The Network SignON Coordinator/2 programs require additional NetBIOS 
resources that may need to be configured as discussed in “Network SignON 
Coordinator/2 NetBIOS Requirements” on page 435. 


The NSC.INI file may be modified by any ASCII file editor (for example, the OS/2 
Enhanced Editor). Each line defines a configuration option or operation. Any line 
beginning with an asterisk is considered to be a comment and is ignored. Any 
text following the first blank (space) character on a line is considered to be 
comment text and is ignored. Although options are all shown in upper case, they 
may be entered in upper, lower or mixed case. 


The options are explained in “Network SignON Coordinator/2 Configuration 
Options.” A complete example of a configuration file is shown in Figure 262. 








USER 
LOCAL 











D=O0S2USR01 


,ON 








LANSERVER, IBM, NAME=ANYDOM01, ON 


























LANSERVER, IBM, NAME=LSDOMAIN1234567,USERID=USERO1 






























































LANSERVER, NOVELL, NAME=NW312 , USERID=NWUSER 


HOST, 1] 





EMULATOR, H1 








[F=C: \NSC\NSCVMOV.HIF,V1=B, V2=AUSVMR , NAME=NEWSES , USERID=VMUSER 
































Figure 262. OS/2 Client NSC.INI File Example 


Network SignON Coordinator/2 Configuration Options 


An option defines how interaction works at a client with an end user and how to 
check their input. The ordering of options is not significant (if duplicate options 
are found, the /ast one will take effect). The options, and where to find out more 
about them, are as follows: 
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- User ID Options 


USERID Default user ID Option 
CHARSET user ID Character Set Option 
+ Menu Parameter Length Options 
MINUIDLEN Minimum user ID Length Option 
MAXUIDLEN Maximum user ID Length Option 
MINPWLEN Minimum Password Length Option 
MAXPWLEN Maximum Password Length Option 
* Other Menu Options 
BEEP Sound Option 
SIGNON Signon Shortcut Option 
SAVEPW Retain Password Option 
CONFIRMEXIT Exit Dialog Option 
DEBUG Problem Determination Option 


The following table provides details of the NSC.INI options that may be set. 





Table 28 (Page 1 of 2). NSC.INI Configuration File Options 


USERID Specifies the user ID to be Any character none 
used for signon operations that is part of the 
user ID 
Character Set 
CHARSET Specifies characters (other Graphic ASCII All alphanumeric 
than alphanumerics) that are characters, other characters plus 
valid in a user IDs and than a space the 
passwords non-alphanumeric 
characters #, @ 
and $ 





MINUIDLEN Defines the minimum user ID 1 to 8 characters 4 characters 
length 

MAXUIDLEN Defines the maximum user ID 1 to 47 8 characters 
length characters 


MINPWLEN Defines the minimum password 1 to 8 characters 5 characters 
length 

MAXPWLEN Defines the maxmum password 1 to 8 characters 8 characters 
length 


BEEP The BEEP option allows the ON, OFF ON 
user to turn on or off the beeps 
that are sounded when error 
messages are displayed or 
invalid keys are pressed 


SIGNON Causes the signon dialog to none none 
immediately be displayed when 
the PM interface (NSC.EXE) is 
started 


SAVEPW Specifies that the end user's ON, OFF OFF 
password should be recorded 
and used for subsequent 
password requests in this 
session 


CONFIRMEXIT Defines whether a warning ON, OFF OFF 
message is displayed before 
Network SignON Coordinator/2 
exits 











442 inside OS/2 LAN Server 4.0 








Table 28 (Page 2 of 2). NSC.INI Configuration File Options 


DEBUG Specifies that additional none none 


information should be logged 
when a problem occurs 





Notes: 


1. Lower case alphabetic characters in the Default user ID will be converted to upper case (see 
user ID Character Set Option). The user ID entered in the Network SignON Coordinator/2 
Signon menu becomes the default user ID for each system specified with a DOMAIN, HOST 
or LOCAL operations. This user ID may be overridden in any of these operations by 
specifying the USERID parameter for the operation. 


2. This option is useful when you use the UPMCSET /E command to extend the user ID 
character set. You can not specify the alphanumeric characters A through Z, a through z, 
and 0 through 9. Only graphic ASCII characters other than a space can be specified. (that is, 
0x21..0x7E, 0x80..0xFE). Lower case extended ASCII characters should be avoided, as they 
will not be converted to upper case, and may not give the desired result when passed to 
UPM or LAN. You can specify up to 159 characters. This is enough to specify all the 
non-alphanumeric graphic ASCII characters. No check is made for duplicate characters. 


3. When specified the equivalent action of using the mouse to select Actions, Signon, and 
Default Systems is performed. 


4. If you select the Default Signons or Change Password actions, the previously entered 
password is used. The password is not stored on disk, but hidden and masked in memory. 
When Network SignON Coordinator/2 is closed, the saved password is no longer available. 


5. This option should only be specified for problem determination purposes since user request 
processing is slower with this option defined. 











Network SignON Coordinator/2 Signon Operation Options 


Network SignON Coordinator/2 signon operations are also defined in the 
configuration file. These operations are: 


Definition To specify 

LOCAL UPM Local signon 

NODE UPM Node signon 

LANSERVER OS/2 LAN or NetWare Server logon 
HOST Host signon 

SERVER NSC/2 Server machine 


The order of the operations is very important since Network SignON 
Coordinator/2 executes them in order. The SERVER definitions are also stored in 
the configuration file. Their position in the file relative to the signon operations 
determines where the signon operations are executed. 


A LOCAL operation is used to make OS/2 UPM password changes and optionally 
logon to the local UPM. This operation is not applicable to DOS Clients. The 
syntax is: 





--LOCAL-[,ON]—[ , USERID=<userid#] EXIT=<filename>] Bois 












































--[, EXITID=<exitid>]- - = as = 


The ON option requests Network SignON Coordinator/2 to perform a local logon 
as well as synchronize password changes with UPM. The ON option is only valid 
on an OS/2 Client. 
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If the user's account on the local workstation is under a different user ID than the 
user ID provided to Network SignON Coordinator/2 (from the USERID 
configuration option, from the command line, from the API, or from the Signon 
dialog), the USERID parameter may optionally be specified. Lower case alphabetic 
characters in the user ID will be converted to upper case. This parameter also 
allows a user to synchronize passwords for multiple accounts on the client 
workstation, each with a different USERID parameter. 



































If the EXIT parameter is optionally provided, Network SignON Coordinator/2 will 
execute the specified command file or executable program for each request 
made for this LOCAL operation. A complete path (up to 80 characters) may be 
specified if the command file or executable program is not in the PATH. See 
“Network SignON Coordinator/2 Exit Routines” on page 448 for more information 
on exit routines and the parameters passed to the exit routines. 











For example, the NSC OS/2 Client will perform a local logon for the user at 
signon and change the password on the client workstation when requested and 
execute the user command file MYEXIT.CMD after each request with the 
following operation: 








LOCAL, ON, EXIT=D: \TOOLS\MYEXIT .CMD 


























Multiple LOCAL operations can be defined within the configuration file to be 
executed either on the Client or at the Server. If no LOCAL operations are 
specified, no local UPM access will be requested. 


A LANSERVER operation is used to make LAN Server password changes and 
optionally logon to the LAN Server. You can specify multiple LAN Server 
definitions to be processed locally, but LANSERVER definitions cannot follow a 
SERVER definition. The syntax is: 


--LANSERVER; IBM | NOVELL} [ -NAME=<name=>] -ON]—[ , USERID=<userid>]-- 



























































--[, EXIT=<filename}] EXITID=<exitid>] = SS - - - ----- 

















The ON option requests Network SignON Coordinator/2 to perform a domain 
logon as well as synchronize password changes with the Domain Controller. 


The value of name is the LAN Server domain or NetWare file server's name. 


If the user's account on the Domain Controller is under a different user ID than 
the user ID provided to Network SignON Coordinator/2 (from the USERID 
configuration option, from the command line, from the API, or from the Signon 
dialog), the USERID parameter may optionally be specified. Lower case alphabetic 
characters in the user ID will be converted to upper case. This parameter also 
allows a user to synchronize passwords for multiple accounts on the same 
Domain Controller by including multiple LANSERVER operations for the same 
Domain Controller, each with a different USERID parameter. 



































lf the EXIT parameter is provided, Network SignON Coordinator/2 will execute the 
specified command file or executable program for each request made for this 
LANSERVER operation. For example, an exit routine could check for a 
successful domain logon and perform a NET USE for a resource controlled by the 
domain. A complete path (up to 80 characters) may be specified if the command 
file or executable program is not in the PATH. See “Network SignON 
Coordinator/2 Exit Routines” on page 448 for more information on exit routines 
and the parameters passed to the exit routines. 
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For example, the Network SignON Coordinator/2 OS/2 Client will perform a LAN 
Server logon for the user on domain MYDOMAIN at signon and change the 
password on domain MYDOMAIN when requested with the following operation: 





LANSERVER , NAME=MYDOMAIN , ON 




















Note: Lower case alphabetic characters in the domain name will be converted 
to upper case. 


Multiple LANSERVER operations can be specified, however they can only be 
executed from the Client. Since it is only possible to have one active domain 
logon on a workstation, only the primary domain should include the ON option. 
LANSERVER operations cannot follow a SERVER definition. 





Network SignON Coordinator/2 Commands and Support Processes 


The following section explains how you interact with Network SignON 
Coordinator/2. 


The way you use Network SignON Coordinator/2 to signon and signoff your 
personal computer depends on which computer interface you prefer: 


Command Line 


If you are familiar with operating system commands, the command line 
interface is an efficient way to perform NSC requests. This interface 
method is also very useful in building customized command files. When 
you type in a command, the results are displayed as text on the screen. 


The command line interface is available for both DOS and OS/2 clients. 


If you create a command file which includes a password, you should 
consider it with regard to security. 


Menu 


The menu interface requests you to enter information at prompt fields. 
Type the required information on the keyboard. This interface does not 
display information entered in password fields. The menu interface is 
available for both DOS and OS/2 clients. 


* Graphical 


A graphical interface lets you enter information, using both the mouse 
and keyboard using OS/2 Presentation Manager to display a window and 
manage that window on your Desktop. A graphical interface is easy to 
use and lets you enter passwords in non-displayed fields. You also have 
easy access to online help information. Network SignON Coordinator/2 
messages are presented in a scrollable area. 


The graphical interface is only available for OS/2 Clients. 
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Using Network SignON Coordinator/2 Commands 
To sign on, use the NSCRSON command. 


The syntax for NSCRSON is: 


- -NSCRSON-- [userid] -- [current-password] -- [new-password] ---- - - 





NSCRSON can be used to change your password by including the new-password 
option. 


To signoff use the NSCRSOFF command. 


The syntax for NSCRSOFF is: 


--NSCRSOFF--~----------------------------------------------------------- 


When NSCRSON and NSCRSOFF terminate, they set the operating system 
ERRORLEVEL to one of the following values: 


ERRORLEVEL Meaning 
0 No errors or warnings 
1 One or more warnings (no errors) 
2 One or more errors 


Accessing the Network SignON Coordinator/2 Interfaces 
To use the menu interface, type NSCRSON and press Enter. If you specify the 
user ID, it overrides any USERID option in NSC.INI. The command syntax is the 
same as that defined in Command Line Interface. 


The graphical interface can be initiated by using the mouse to open the icon 
representing Network SignON Coordinator/2 or by issuing the following 
command. 


NSC 


A Presentation Manager window is presented, giving you the option to signon, 
signon and change passwords or signoff. 








Local : 


OS2USROZ 


IBM LAN Server i 
ANYDOMOI i 
OS2USR03 


Figure 263. Network SignON Coordinator/2 Presentation Manager Interface 
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Network SignON Coordinator/2 Support Processes 


NSC provides two support processes to help you keep your password changes 
synchronized more easily and to extend your connection to either another OS/2 
or host system. 


These support processes are: 


* NSCRETRY - Enable Retries 
- NSCNDMN - Start the NSC Server 


NSCRETRY creates a queue for requests that originally failed and retries these 
requests at set intervals. The retry queue is lost in a power failure or when you 
shutdown the workstation. By default, outstanding requests will be retried three 
times at fifteen minute intervals. The number of retries and the retry interval are 
configurable. NSCRETRY is installed on the NSC OS/2 Client and on the NSC 
Server. 


Start NSCRETRY from STARTUP.CMD or from the OS/2 System Startup folder (in 
OS/2 2.X). NSCRETRY may be run as a windowed or full screen program. If a 
request has been queued for retry, once the situation causing the original failure 
has been remedied, you should check the NSCRETRY output messages to verify 
that the request was processed. 


Note: Be sure that exit routines in DOS do not write to the screen (to avoid 
overwriting the Network SignON Coordinator/2 menu). 


eoowe 





Fy 
H 
Fy 
ik 
Fy 
ik 
Fy 
HH 
Fy 
HH 
Hy 
ik 
Hy 
ik 
Fy 
HH 
Fy 
ik 
Hy 
ik 
Fy 
ik 
Hy 
FH 
Hy 
HH 
Fy 
H 
Fy 
ik 
Fy 
ik 
Hy 
ik 
Fy 
ik 
Fy 
ik 
Fy 
ik 
Fy 
ik 
Hy 
ik 
Fy 
HH 
Fy 
ik 
Fy 
ik 
Fy 
ik 
Hy 
HH 
Fy 
ik 
Fy 
ik 
Fy 
ik 
Fy 
ik 
Fy 
ik 
Fy 
ik 
Fy 
ik 
Fy 
ik 
Hy 
ik 
Fy 
ik 
Fy 
ik 
Fy 
ik 
Fy 
ik 
Fy 
ik 
Hy 
i 
Hy 
ik 
Fy 
HH 
ie 
Fy 
or 


x 
s 
s 
g 
BS 
g 
BS 
q 
3 
g 
BS 
BS 
S| 
gl 
BS 
By 
s 
By 
s 
BS 
BS 
By 
BS 
g 
S| 
g 
S| 
By 
S| 
BS 
s 
q 
S| 
ql 
S| 
BS 
S| 
g 
S| 
By 
s 
q 
S| 
BS 
S| 
g 
S| 
By 
S| 
g 
BS 
By 
S| 
g 
S| 
g 
S| 
g 
BS 
BS 
BS 
By 
S| 
By 
S| 
g 
s 
BS 
S| 
BS 
BS 
By 
S| 
g 
s 
q 
S| 
g 
S| 
g 
S| 
g 
BS 
q 
BS 
BS 
BS 
q 
a 
S 
3 
By 
S| 
BS 
S| 
g 
BS 
By 
s 
g 
S| 
q 
S| 
g 
S| 
ql 
s 
By 
BS 
By 
s 
g 
BS 
g 
BS 
g 
s 
g 
S| 
By 
S| 
g 
S| 
g 
S| 
q 
S| 
g 
S| 
g 
BS 
g 
BS 
By 
S| 
g 
BS 
q 
s 
By 
s 
By 
3 
g 
S| 
g 
S| 
g 
BS 
q 
S| 
g 
s 
BS 
BS 
q 
q 
Bo 


Figure 264. Network SignON Coordinator/2 Retry Process Window 
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Network SignON Coordinator/2 Exit Routines 

Exit routines in OS/2 are started in a separate session in the background, and 
may be windowed, full screen or PM applications. The session inherits the 
environment of the Network SignON Coordinator/2 session. Exit routines that end 
with an extension of started using the command interpreter as a windowed 
session. All other exit routines are started as executable programs. 
Exit routines are called with the following parameters: 

1. Either 

* 0 for a signon or signon and change password request 
1 for a signoff request 
2. The configuration index of the associated option (the first option is 1) 


3. The return code from the request for the associated option (for example, LAN 
Server, host, or local UPM). Return codes are listed in the NSCRSIGN.H 
header file. 


4. user ID (may be blank for Sign Off) 
5. Current Password (blank for Sign Off) 


6. New Password (blank for Sign Off or if password was not changed) 
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Appendix C. Open Blueprint 


© Copyright IBM Corp. 1995 


This appendix gives you an overview of Open Blueprint, IBM's technical 
approach for integrated, open, client/server, and distributed computing across 
systems platforms. The structure includes industry-standard interfaces, 
protocols, and formats, and IBM extensions to provide the flexibility to 
accommodate new technologies as they emerge in today's dynamic open 
computing environment. 


Note: Open Blueprint builds on the IBM Networking Blueprint (a plan and 
direction for multivendor networking announced by IBM in 1992) by providing 
more detail and structure on the Application Support Layer. It will evolve with 
the Networking Blueprint. 


Open Blueprint defines facilities for developing, implementing, and managing 
applications across a broad range of systems. Based on both formal and de 
facto industry standards, it provides interoperability among IBM's and other 
vendors’ systems. This addresses the requirement for a platform-independent 
structure for information sharing in a distributed, multivendor environment. This 
structure addresses individual Desktop computers, LANs and mid-range and 
mainframe computers. 


Open Blueprint allows the development, execution and management of 
distributed applications and distributed services in an open, extendable fashion. 
It provides an integration framework so multiple vendors offerings can work 
together to provide a unified open system solution. Also, the structure lets 
applications be developed that can execute independent of the location of 
resources. 


Open Blueprint defines a set of resource managers (also called enablers or 
services) that manage and provide access to computing resources such as data, 
applications or presentation to a user. Many resource managers are divided into 
client and server sections to allow flexibility in placement in the network. The 
structure encourages consistency of interfaces and protocols and enables 
interoperability across the network. 


The structure defines functions that might be a part of any system in a network, 
from a PC on a desk to an enterprise data server. However, not all functions 
would necessarily be needed on each system. Resource managers can be 
functionally grouped into sets of services: 


Network Services provide for the transport of data from an end point in one 
system to an end point in another. Network Services include the Transport 
Network and Subnetworking components in Open Blueprint. 


Distributed Services provide common mechanisms to assist the parts of a 
distributed application or resource manager to communicate. Security and 
directory services are examples. 


Communication Services are mechanisms for parts of a distributed 
application or resource manager to talk with each other. 


Object Management Services provide transparent access to local and remote 
objects. 


Data Access Services allow applications to access various types of data. 


449 


450 


* Presentation Services define the interaction between applications and the 
user via various devices. 


* Application Services are common functions that have been developed once 
and in a standard way. 


* Systems Management Services provide the systems administrator with the 
facilities to manage a distributed computing environment. 


+ Local Operating System Services operate within the confines of a single 
system network. Examples of such services are memory management and 
the dispatching of work. 
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Figure 265. Open Blueprint Structure 


Components in the structure can be provided by a variety of vendors. However, 
these components will not be delivered all at one time, and not every 
combination of components may be needed in any given system. Many 
components are available today, and others will be provided as they are 
required or as technologies evolve. 


Applications (and resource managers) request services from resource managers 
using standard interfaces. Resource manager communication among client and 
server portions are based on broadly accepted industry standard formats and 
protocols. This permits other vendors' systems to participate equally in the 
network as either clients or servers. The Open Blueprint includes standard 
interfaces and protocols from those specified in X/Open's Distributed Computing 
Services Framework, as well as many others required in today's open distributed 
environment. 
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For more information, see the Open Blueprint Technical Overview manual and 
the Open Blueprint Introduction white paper. 


The functions included in the Transport Network, Subnetworking, and Systems 
Management are the same as those in the IBM Networking Blueprint (a plan and 
direction for multivendor networking announced by IBM in 1992), and will evolve 
with the Networking Blueprint. The Open Blueprint builds on the IBM Networking 
Blueprint by providing more detail and structure in the Networking Blueprint's 
Application Support Layer. 


Multiprotocol Transport Networking 


IBM recognizes the need to support a variety of network protocols in use today 
for sending information throughout the network, involving both wide area and 
local area parts of the network. 


These protocols include DECnet, IPX (Internetwork Packet Exchange), NetBIOS, 
OSI (Open Systems Interconnection), SNA (Systems Network Architecture), and 
TCP/IP (Transmission Control Protocol/Internet Protocol). Each protocol has 
associated interfaces used to access their services. 


The Open Blueprint includes Sockets, an API being standardized by both X/Open 
and POSIX, as a transport interface. 


The Multiprotocol Transport Networking (MPTN) architecture provides a common 
view of network protocols through common transport semantics. It allows 
applications to be independent of the underlying network transport and allows 
networks with different protocols to be interconnected by use of transport 
gateways. This function gives users choice and flexibility in their application and 
networking decisions. 


MPTN is complementary to X/Open's Transport Interface (XTI) and will allow for 
XTI as it evolves. MPTN permits application programs that were designed to 
operate over a particular transport network, such as TCP/IP, to run over 
additional networks, such as SNA/APPN, OSI, or NetBIOS. MPTN shields the 
application program from the network differences. XTI is a multi-faceted interface 
that provides access to OSI, TCP/IP, and NetBIOS but does not shield the 
application from the network differences. IBM has developed MPTN-based 
products, and has submitted the architecture to X/Open. 
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Here is a brief overview of OS/2 LAN Server 4.0 and the Macintosh client 
interoperability. For more information, see the OS/2 LAN Server for Macintosh 
Administrator's Guide. 
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Figure 266. OS/2 LAN Server 4.0 and Macintosh Interoperability 
During our testing we used the following components: 


Hardware 
IBM PS/VP Model 6387 
IBM ISA Token-Ring Adapter 
Novell NE2000 Ethernet Adapter 
Macintosh LC 
* Apple Ethernet Adapter 


Software 
OS/2 LAN Server 4.0 


OS/2 LAN Server for Macintosh version 1.0 with the LSMMOD8 fix applied 
(from the LSMACFIX package) 


Macintosh System 7.0 
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-—— Warning 


The LAN Server for Macintosh product requires the LSMMOD8 module, which 
is part of the LSMACFIX package, in order to work with OS/2 LAN Server 4.0. 
You can get the LSMACFIX package from IBM support, or for IBM 
employees, from the OS2CSD tools disk. 











Introduction 

Macintosh is a computer platform based on Motorola's microprocessor, using a 
operating system developed by Apple Computer, Inc.. The Macintosh computer 
has integrated within it the necessary components to build a network. Macintosh 
uses the AppleTalk protocol stack, developed by Apple Computer, to 
communicate on the network. 


For Macintosh users to access OS/2 LAN Server, an additional component on 
OS/2 LAN Server is necessary to make translations between the computers 
platforms. IBM has developed the product OS/2 LAN Server for Macintosh 
(LSM). The purpose of the product is make LAN Server resources available to 
Macintosh users. 


Note: Hereafter we will use LSM as an abbreviation of the LAN Server for 
Macintosh product. 


LSM is a separate product from OS/2 LAN Server and was was designed to 
match the OS/2 LAN Server 3.0 functionality. For this reason, some limitations, 
such as the long name restriction documented below, still exists. The product is 
compatible with OS/2 LAN Server 2.0, 3.0 and 4.0 (with CSD LSMMOD8). 


-— Long Name Restriction 


Be aware that if you have LAN Server for Macintosh clients, there is currently 
a problem if you use names more than eight characters in length. /f there 
are LAN Server for Macintosh clients in your network, do not use more than 
eight characters for your names. 











Macintosh clients are connected to LSM using the AppleTalk protocol stack. The 
file and print server functions are based on the AppleTalk protocol stack and 
communicate with LAN Server through APIs on the OS/2 LAN Server 4.0 end. 


The AppleTalk for Macintosh client is installed with system software that is 
included with the Macintosh computer hardware, or it can also be installed using 
the appropriate diskette that comes with the Macintosh network adapter. 


LSM uses the printer, queue, group and user definitions from OS/2 LAN Server 
4.0 accounts database. These definitions can be made using the GUI provided 
with the OS/2 LAN Server 4.0. 


You can find more details on OS/2 LAN Server for Macintosh in the OS/2 LAN 
Server for Macintosh Administrator's Guide. 
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Installing LSM on OS/2 LAN Server 4.0 

You don't need to install additional products on the Macintosh workstation. 
Rather, you only need to install LSM on the OS/2 LAN Server 4.0 and apply CSD 
LSMMOD8. This allows LSM to work with OS/2 LAN Server 4.0. 


The installation of LSM is simple and Presentation Manager-based. The 
installation process begins by entering LSMINST at the command prompt. During 
our tests, we used LSM 1.0 and applied CSD LSMMOD8, as shown in the 
following instructions. 





On OS/2 LAN Server 4.0 Workstation: 
1. Insert the LSM diskette in the drive, and type: 
A: LSMINST 





2. After the installation is complete, do not reboot the machine as instructed by 
the installation program. Instead, stop the server by entering the command: 





NET STOP SERVER /Y 


3. Put the LSMMOD8 CSD in the drive and make this drive your current drive. 
Execute LSMREPL %1 %2, where %1 is the drive where the LS4.0 and the 
LSM are installed, and %2 is the OS/2 boot drive. 

















A: <Enter> 
A:\LSMREPL C D 











Note that the LSMMOD8 will copy several files to the hard disk. Be sure that 
all copies are successfully completed. 


4. Reboot your machine. 


On the Macintosh Workstation: There is no additional product on the Macintosh 
client. You just need to configure the software to use the right network media. 
In our case, we used EtherTalk to access the OS/2 LAN Server 4.0. 


1. On Macintosh main panel, press and hold the mouse button over the Apple 
symbol. A menu will appear. 


2. From the menu, select the Control Panels option. The Control Panels 
window will appear. 


3. Find the Network icon and double-click it. The Network panel will appear. 


4. Choose your network option. In our case, this is EtherTalk. 


LSM is installed, and the Macintosh computer is ready to access the OS/2 LAN 
Server 4.0. 


Hints and Tips 

After LSM is started, any user at a Macintosh workstation can access the OS/2 

LAN Server 4.0 through the Macintosh Chooser, as long as the LSMMOD8 fix is 
applied. During our tests, LSM worked well if we played by the LAN Server 3.0 
naming conventions. 


From Macintosh's point of view, you can still log on to OS/2 LAN Server 4.0 
using the Macintosh user name of up to 31 characters. LSM is configured to 
map the 31 characters of the Macintosh user name to an eight-character user ID 
on OS/2 LAN Server. 
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From the OS/2 LAN Server 4.0 point of view, you can have a user ID with up to 
20 characters. However, the LAN Server for Macintosh 1.0, which was developed 
during the LAN Server 3.0 timeframe, is not able to understand user IDs that 
exceed 8 characters. For this reason, the limit for the user ID of Macintosh 

users is still 8 characters. 


LSM 1.0 uses the user database created by OS/2 LAN Server 4.0. The product 
itself does not create users; it simply maps long user names from Macintosh 
computers to OS/2 LAN Server 4.0 user IDs. Due to the product design LSM 1.0 
does not understand the user ID that exceeds eight characters. 


Another restriction is that the Macintosh users are not able to see LSM servers 
across an 8209 bridge. 


Macintosh clients do not respect the HPFS386 drive and directory limits of the 
OS/2 LAN Server 4.0. For example, if you assign a DASD limit to an HPFS386 
directory to restrict the size for the users, this limit is ignored by Macintosh 
users. They are able to exceed the DASD limit, because LSM sees this as local 
access, not network access. Local access is always exempt from the DASD 
limits set on HPFS386 drives and directories. 


Using the Macintosh client, you are able to: 


+ Use the GUEST account privileges to access the OS/2 LAN Server 4.0 


+ Log on to OS/2 LAN Server 4.0 as a regular user (using a user ID of eight 
characters or less) 


+ Connect to a files alias on LAN Server 4.0 
Connect to printer alias on LAN Server 4.0 
+ Receive directory logon assignments, including: 


- Home directory 
- File assignments 


Receive the public applications 


Actually, you cannot run the applications, but you can connect to the 
application alias. 


You will not be able to: 
+ Manage the server functions (such as creating users, groups, and aliases) 
+ Receive your printer assignments 


« Run public applications 


Configuration Files 
The following are the configuration files used in this test. 


CONFIG.SYS 


IFS=C: \IBM386FS\HPFS386.IFS /A:* 
PROTSHELL=C: \OS2\PMSHELL . EXE 
ET USER_INI=C:\0S2\0S2.INI 
T SYSTEM_INI=C:\O0S2\O0S2SYS.INI 
T OS2_SHELL=C: \OS2\CMD. EXE 
T AUTOSTART=PROGRAMS , TASKLIST, FOLDERS , CONNECTIONS 
TT RUNWORKPLACE=C: \OS2\PMSHELL. EXE 
TT COMSPEC=C: \OS2\CMD. EXE 
LIBPATH=C: \MPTN\DLL; C: \IBMCOM\DLL; C: \IBMLAN\NETLIB;C: \MUGLIB\DLL; . 
7C:\OS2\DLL ; C:\OS2\MDOS;C:\;C:\OS2\APPS\DLL;C: \NVDM2V21\DLL; 
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ET PATH=C:\MPTN\BIN;C:\IBMCOM;C:\IBMLAN\NETPROG;C:\MUGLIB;C:\0S2; 
: \OS2\SYSTEM; C: \OS2\MDOS\WINOS2;C:\OS2\ INSTALL; C:\;C:\OS2\MDOS; 
:\OS2\APPS;C: \NVDM2V21\BIN; 

ET DPATH=C: \IBMCOM;C:\IBMLAN\NETPROG;C:\IBMLAN;C:\MUGLIB;C:\0S2; 
OS2\SYSTEM;C:\OS2\MDOS\WINOS2 ;C:\OS2\INSTALL;C:\;C:\OS2\BITMAP; 
OS2\MDOS;C:\OS2\APPS;C:\NVDM2V21;C:\IBM386FS; 

PROMPT=$i [$p* 

T HELP=C:\O0S2\HELP;C:\O0S2\HELP\TUTORIAL; C: \IBMLAN\NETPROG; 
ET GLOSSARY=C: \OS2\HELP\GLOSS; 

T IPF_KEYS=SBCS 
RIORITY_DISK_IO=YES 
ES=20 

EVICE=C : \IBMCOM\PROTOCOL\LANPDD .OS2 

EVICE=C : \ IBMCOM\ PROTOCOL\LANVDD.OS2 

EVICE=C: \IBMCOM\LANMSGDD.OS2 /I:C:\IBMCOM 

EVICE=C: \IBMCOM\PROTMAN.OS2 /I:C:\IBMCOM 

EVICE=C: \OS2\TESTCFG. SYS 

EVICE=C:\O0S2\DOS.SYS 

EVICE=C:\O0S2\PMDD.SYS 

UFFERS=30 

OPL=YES 

KCACHE=1024, LW 

WAIT=3 

MMAN=SWAP, PROTECT 

WAPPATH=C: \OS2\SYSTEM 2048 2048 

REAK=OFF 

HREADS=256 

INTMONBUFSIZE=134,134,134 
&TRY=001,C:\0S2\SYSTEM\COUNTRY. SYS 

EYS=ON 

ET DELDIR=C: \DELETE, 512;D:\DELETE,512;E:\DELETE,512; 
LETE,512;Y:\DELETE,512; 

EV=PRINTO1.SYS 
EV=IBM1FLPY.ADD 
EV=IBM1S506.ADD 
EV=OS2DASD. DMD 
Ss OOKSHELF=C: \IBMLAN\NETPROG; C: \OS2\BOOK 
SE PMPATH=C : \OS2\APPS; 

REM DEVICE=C: \OS2\APPS\SASYNCDA. SYS 
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ROTECTONLY=NO 
HELL=C : \OS2\MDOS\COMMAND.COM C:\0S2\MDOS 








EVICE=C: \OS2\MDOS\VEMM. SYS 
OS=LOW, NOUMB 
EVICE=C: \OS2\MDOS\VXMS.SYS /UMB 
EVICE=C:\OS2\MDOS\VDPMI.SYS 

EVICE=C: \OS2\MDOS\VDPX.SYS 

EVICE=C: \OS2\MDOS\VCDROM. SYS 
EVICE=C: \OS2\MDOS\VWIN.SYS 
EVICE=C:\OS2\PCMCIA.SYS 

EVICE=C: \OS2\MDOS\VPCMCIA. SYS 
EVICE=C: \OS2\MDOS\VMOUSE. SYS 
EVICE=C:\O0S2\POINTDD. SYS 

EVICE=C: \OS2\MOUSE. SYS 
EVICE=C:\OS2\COM.SYS 

EVICE=C: \OS2\MDOS\VCOM. SYS 
ODEPAGE=437, 850 
'VINFO=KBD, US, C:\OS2\KEYBOARD. DCP 

T RestartObjects=StartupFoldersOnly 
auseOnError=No 
EVINFO=SCR, VGA, C: \OS2\VIOTBL. DCP 
ET VIDEO_DEVICES=VIO_SVGA 

ET VIO_SVGA=DEVICE (BVHVGA, BVHSVGA) 
EVICE=C: \OS2\MDOS\VSVGA. SYS 
ALL=C: \IBMCOM\PROTOCOL\NETBIND. EXE 
UN=C : \ IBMCOM\ LANMSGEX. EXE 
EVICE=C: \MPTN\PROTOCOL\MPTN. SYS 

EVICE=C: \MPTN\PROTOCOL\LIPC.SYS 

UN=C: \MPTN\BIN\CNTRL.EXE /P mptn_os$ 
ALL=C:\OS2\CMD.EXE /Q /C C:\MPTN\BIN\MPTSTART.CMD 
EVICE=C: \IBMCOM\PROTOCOL\NETBEUI .OS2 

EVICE=C: \IBMLAN\NETPROG\RDRHELP. 200 

FS=C: \IBMLAN\NETPROG\NETWKSTA.200 /I:C:\IBMLAN /N 
EVICE=C: \IBMCOM\PROTOCOL\NETBIOS.OS2 
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UN=C : \IBMCOM\ PROTOCOL \LANDLL . EXE 








EVICE=C: \NVDM2V21\BIN\anxifpid.sys 
EVICE=C: \NVDM2V21\BIN\anxifcom.sys 
FS=C: \NVDM2V21\BIN\anxifcom.i 
EVICE=C: \NVDM2V21\BIN\ANXACAT 
EVICE=C: \IBMCOM\PROTOCOL\LANDD.OS2 

EVICE=C: \ IBMCOM\ PROTOCOL\LANDLLDD.OS2 
EVICE=C: \IBMCOM\MACS\NE2000.0S2 


fs 
P.SYS 














UN=C : \ IBMLAN\NETPROG\ LSDAEMON . EXE 




















ET INIT_FILE_NAMES=netgui 
ET INIT_FILE_RANGES=200 




















s 





[ WPS_COMMUNICATION=YES 








T LANG=ENUS437 

EVICE=C: \ IBMLAN\NI 
EVICE=C: \IBMLAN\NI 
ET ETC=C:\MPTN\ETC 

















E 
E 
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PROTOCOL.INI 


[PROT_MAN] 





DRIVERNAME = PROTMANS 











[IBMLXCFG] 


LANDD_nif = LANDD.NIF 


ET NWDBPATH=C: \IBMLAN\NETPROG 
ET DLSINI=C: \IBMLAN\NETPROG\NI 








ET LOCPATH=C: \IBMLAN\XPG4\LOCALI 








NETBEUI_nif = NETBEUI.NIF 











IBMNE200_nif = IBMNE200.nif 








IBMTOK_nif = IBMTOK.nif 


[NETBIOS] 





DriverName = netbioss$ 
ADAPTERO = netbeuiS,0 
ADAPTER1 = netbeuiS,1 








[APPLETALK] 





DriverName = ATALKS 
Bindings = IBMNE200_nif 
MAXSESSIONS = 64 

RXBUFS = 16 

TXBUFS = 16 

BUFSIZE = 1584 

zone=* 











[LANDD_nif] 


DriverName = LANDDS 
Bindings = IBMNE200_nif 
ETHERAND_TYPE = "I" 
SYSTEM_KEY = 0x0 
OPEN_OPTIONS = 0x2000 
TRACE = 0x0 

LINKS = 8 

MAX SAPS = 6 
MAX_G_SAPS = 0 

USERS = 6 

TI_TICK_G1 = 255 
T1_TICK_G1 = 15 
T2_TICK_G1 = 3 
TI_TICK_G2 = 255 
T1_TICK_G2 = 25 
T2_TICK_G2 = 10 
IPACKETS = 250 
UIPACKETS = 10 




















MAXTRANSMITS = 6 
MINTRANSMITS = 2 
TCBS = 64 
GDTS = 30 
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ETGUI.INI 





Gl 


TPROG\ATALK.SYS 
TPROG\ATKP.SYS 


EVICE=C: \IBMCOM\MACS\IBMTOK.0OS2 
UN=C: \IBMLAN\NETPROG\ATKINIT. 








EXE 











ELEMENTS = 1200 














[NETBEUI_nif] 











verName = netbeui$ 

Bindings = IBMNE200_nif, IBMTOK_nif 
ETHERAND_TYPE = "I" 

USEADDRREV = "YES" 

OS2TRACEMASK = 0x0 





























Ss 

N 

NAMES = 21 
SELECTORS = 30 
USE 

A 

W 











EMAXDATAGRAM = "NO" 
DAPTRATE = 1000 
INDOWERRORS = 0 
MAXDATARCV = 4168 
TI = 30000 
T1 = 1000 
T2 = 200 
MAXIN = 1 
MAXOUT = 1 
NETBIOSTIMEOUT = 500 
NETBIOSRETRIES = 2 
NAMECACHE = 1000 
RNDOPTION = 0 
PIGGYBACKACKS = 1 
DATAGRAMPACKETS = 
PACKETS = 350 
LOOPPACKETS = 8 
PIPELINE = 5 
MAXTRANSMITS = 6 
MINTRANSMITS a 
DLCRETRIES = 
FCPRIORITY = 
NETFLAGS = 0x 










































































0 








1 
5 
0 





[IBMNE200_nif] 








DriverName = NE2000E$ 
IToaddress = 0x0300 
Interrupt = 3 

Ram = 0x0D0000 











[IBMTOK_nif] 


DriverName = IBMTOKS 
ADAPTER = "PRIMARY" 
MAXTRANSMITS = 6 
RECVBUFS = 2 
RECVBUFSIZE = 256 
XMITBUFS = 1 




















IBMLAN.INI 


[networks] 





netl 
net2 


I 





NETBEUIS,0,LM10,102,175,14 
NETBEUIS,1,LM10,102,175,14 

















[requester] 





COMPUTERNAME = SKYWALKER 
DOMAIN = LSDOMAIN1234567 
charcount = 16 

chartime = 250 

charwait = 3600 

keepconn = 600 
keepsearch = 600 

maxcmds = 16 

maxerrorlog = 100 
maxthreads = 10 
maxwrkcache = 64 
numalerts = 12 
numcharbuf = 10 
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numservices = 19 
numworkbuf = 15 
numdgrambuf = 14 
othdomains = itscaus 
printbuftime = 90 
sesstimeout = 45 
sizcharbuf = 512 
sizerror = 1024 
sizworkbuf = 4096 
useallmem = No 
wrkheuristics = 11111111213111111100010111201112210012111 
WRKSERVICES = MESSENGER 
wrknets = NET1,NET2 



































[messenger ] 


logfile = messages.log 
sizmessbuf = 4096 


[netlogon] 
SCRIPTS = C:\IBMLAN\REPL\IMPORT\SCRIPTS 


pulse = 60 
update = yes 





[replicator] 


replicate = IMPORT 

IMPORTPATH = C:\IBMLAN\REPL\ IMPORT 
tryuser = yes 

password = 

interval = 5 

guardtime = 2 

pulse = 3 

random = 60 





[dcdbrep1 ] 


tryuser = yes 
password = 
interval = 5 
guardtime = 2 
pulse = 3 
random = 60 


[server] 


alertnames = 
auditing = resource 
autodisconnect = 120 
maxusers = 101 
guestacct = guest 
accessalert = 5 
alertsched = 5 
diskalert = 5000 
erroralert = 5 
logonalert = 5 
maxauditlog = 100 
maxchdevjob = 6 
maxchdevgq = 2 
maxchdevs = 2 
maxconnections = 300 
maxlocks = 64 
maxopens = 256 
maxsearches = 350 
maxsessopens = 256 
maxsessreqs = 50 
maxsessvcs = 1 
maxshares = 192 
netioalert = 5 
numbigbuf = 12 
numfiletasks = 1 
numreqbuf = 250 
sizreqbuf = 4096 
srvanndelta = 3000 
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srvannounce = 180 

srvhidden = no 

srvheuristics = 111101411113110013311 

SRVSERVICES = NETLOGON, LSSERVER, 1smfile,1smprintin, lsmprintout 
srvnets = NET1,NET2 

autopath = 









































[alerter] 
sizalertbuf = 3072 
[netrun] 


maxruns = 3 
runpath = C:\ 


[lsserver] 


cleanup = no 
srvpipes = 5 


[services] 


alerter = services\alerter.exe 
dcdbrepl = services\dcdbrepl.exe 
lsserver = services\lsserver.exe 
messenger = services\msrvinit.exe 
netlogon = services\netlogon.exe 
netrun = services\runservr.exe 
replicator = services\replicat.exe 
requester = services\wksta.exe 
server = services\netsvini.exe 
timesource = services\timesrc.exe 
lsmfile=services\lsmfile.exe 
lsmprintin=services\lsmpin.exe 
lsmprintout=services\lsmpout.exe 


[lsmfile] 
syspath=C: \ibmlan\lsm 
allowsavepassword=true 
audittrail=false 
maxopenfiles=40 
encryptedlogin=false 


[lsmprintin] 
syspath=C: \ibmlan\lsm 


[lsmprintout] 
syspath=C: \ibmlan\lsm 
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Index 


Numerics 
32-bit application enhancement 133 
386 HPFS 

See HPFS386 


A 
access control list, HPFS386 215 
Access Control Manager utility 233 
access control profile 

creating 13 
account, user 9 
acknowledgments — xxii 
ACL utilities 151 
adapter sniffing 2 
adapters, MPTS 384 
adapters, supporting multiple 137 
additional server, defining 28 
administration utilities 6 
administration, domain 24 
alerts, directory limits 221 
AnyNet 

See Multiprotocol Transport Services 
API enhancements 113, 133 
Apple Macintosh support 453 
AppleTalk 454 
applets 

See utilities 
application licenses 16, 20 
applications, network 5 
architecture 

HPFS386 206 

Multiprotocol Transport Network 1, 451 


BACKACC utility 154, 421 
backup DCDB_ 275 

backup domain controller 275 
backup utilities 421 

boot diskettes, HPFS386 216 
boot drive, recovering 260 
broadcast file, TCP/IP 48 
buffers, requester 141 


C 


caching, HPFS386 208 
CASSETUP utility 5, 363 
character translation, DLS 94 
clipboard, network 4, 32 
code page considerations, DLS 94 
code server setup 

code server setup 

manual 376 
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code server setup (continued) 
code server setup (continued) 
using CASSETUP 361 
manual 376 
using CASSETUP 361 
coexistence 151 
among LAN Server versions 151 
logon/admin capabilities 157 
TCPBEUI and NetBIOS 47 
TCPBEUI and TCP/IP for OS/2 47 
with Microsoft and Novell products 161 
commands, new and changed _ 5, 113 
DLS commands 129 
extensions for peer services 106 
NET ACCESS 116 
NET APP 117 
NET DASD 119 
NET TIME 121 
NET USER 122 
table 124 
common transport semantics 2 
connections, persistent 70 
cross-domain resources 26 
CSD 
LAN Server for Macintosh 453 


D 


DASD limit 3, 119, 218 
DB2 CAE for OS/2 
remote IPL setup 339 
DB2 CAE for Windows 
remote IPL 349 
DB2/2 
installing DB2 Server for OS/2 340 
DCDB backup 275 
DDE 
See dynamic data exchange 
defining 
access control profiles 13 
additional servers 28 
machines 28 
public applications 15 
shadowed servers 29 
users and groups 8 
device drivers, virtual 411 
directory limits 3, 218 
directory-full alerts 222 
disk geometry 244 
disk mirroring/duplexing 237 
distributed computing 
Open Blueprint 449 
distributing software 359 
domain controller, backup 275 
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domain name server, TCP/IP 49, 50 
domains, managing 24 
DOMAINSCOPE parameter 49 
domainscope parameter, NetBIOS 50 
DOS LAN Requester 71 
DOS LAN Services 63, 65 
ClD-enablement 71 
code page considerations 94 
coexistence with TCP/IP 87 
commands, new and changed 129 
comparison with DOS LAN Requester 68 
installing 73 
installing on OS/2 83 
installing with Windows 79 
interoperability with DLR 71 
local logon 70 
memory requirements 68 
NetBIOS over TCP/IP 91 
NETWORK.INI file 84 
overview of changes 2 
peer services 68 
performance 71 
upgrading from DLR 72 
virtual device driver 414 
drag-and-drop of objects 7 
duplexing, disk 237 
dynamic data exchange 4, 32 
dynamic link library considerations 23 


E 


encoding NetBIOS names for TCPBeui 50 
enhancements in LAN Server 4.0 1 
external resources 26 


F 

failed boot drive 260 

fault tolerance 237 

file system, HPFS386 3, 205 
FIXACC utility 423 

Fnode, HPFS386 215 


G 


gateway, interoperability 203 
geometry of disks 244 
graphical user interface 1, 7, 66 

DOS LAN Services 66 
groups, managing 8 
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